Gerenciamento de energia do subsistema de áudio para plataformas de espera modernas

Cada PC com Windows tem um subsistema de áudio que permite ao usuário ouvir e gravar som de alta qualidade em tempo real. Uma plataforma de hardware que aceita o modelo de energia em espera conectado normalmente se baseia em um circuito integrado de SoC (sistema-em-um-chip) que conta com unidades de processamento de áudio integradas e de baixo consumo de energia.

As unidades de processamento de áudio descarregam o processamento de áudio de um ou mais processadores principais no SoC. Como essas unidades podem processar dados de áudio sem usar o processador principal, o usuário pode continuar ouvindo áudio mesmo depois que o processador principal entra em um estado de baixo consumo de energia para economizar a bateria.

Este vídeo mostra como usar o WPA (Windows Performance Analyzer) para verificar se um computador entra no estado de baixo consumo de energia durante a reprodução de áudio com a tela desligada (também conhecido como áudio de baixo consumo de energia ou LPA).

O artigo a seguir fala sobre o gerenciamento de energia do subsistema de áudio para plataformas em espera conectadas. Na discussão a seguir, o termo componente em SoC descreve um componente que está integrado ao chip SoC. Um componente fora do SoC é externo ao chip do SoC.

Visão geral do subsistema de áudio

Além dos blocos de função do SoC que fazem o processamento de áudio descarregado, cada plataforma de espera conectada inclui um componente fora do SoC, chamado codec, que faz o seguinte:

• Traduz fluxos digitais decodificados em sons analógicos.
• Aciona alto-falantes integrados.
• Aciona fones de ouvido analógicos conectados externamente.

Como em um subsistema de câmera, o subsistema de áudio conta com componentes dentro e fora do SoC. No entanto, o Windows espera que um único driver de áudio gerencie os mecanismos de processamento de áudio dentro do SoC e o codec fora do SoC. Esse único driver de áudio é responsável por gerenciar os componentes integrados ao SoC e os componentes fora do SoC que podem ser selecionados pelo integrador de sistemas. Portanto, o integrador de sistemas deve trabalhar em estreita colaboração com o fornecedor do silício de SoC na integração do subsistema de áudio e no gerenciamento de energia.

O fornecedor de hardware de áudio deve implementar o driver de áudio como um driver de miniporta de classe de porta (Portcls). O driver de áudio funciona em conjunto com o driver de sistema Portcls, Portcls.sys, que é um componente da caixa de entrada do Windows.

Em comparação com outras classes de dispositivos, o subsistema de áudio faz um tipo de gerenciamento de energia exclusivo quando a plataforma está no estado de energia em espera conectado (ou seja, quando a tela está desligada). Quando a plataforma está conectada em espera, o sistema pode gerar sons de áudio para notificar o usuário em relação a eventos (por exemplo, a chegada de um novo email) em tempo real. Além disso, o usuário pode desligar a tela do sistema e, em seguida, continuar ouvindo o áudio que está sendo reproduzido por um aplicativo. Esses recursos não podem ser alcançados por uma estratégia simples de gerenciamento de energia na qual o subsistema de áudio deve ser desligado quando o sistema está no modo de espera conectado. Em vez disso, o gerenciamento de energia do subsistema de áudio sempre deverá ser executado em modo ocioso no tempo de execução (para que seja ligado somente quando necessário), exceto quando o sistema estiver no estado de desligamento ACPI (S5).

O driver de áudio executa o gerenciamento de energia em modo ocioso no tempo de execução em estreita cooperação com a infraestrutura de áudio do Windows e o driver do sistema PortCls. O PortCls monitora todos os acessos (como E/S e acessos de propriedade) do dispositivo de áudio e redefine o temporizador do tempo ocioso em cada acesso. Se o temporizador do tempo ocioso expirar, o PortCls fará a transição do dispositivo de áudio (com a ajuda do driver de áudio) para um estado de suspensão de baixo consumo de energia (D3). O PortCls retornará o dispositivo de áudio para o estado ativo (D0) se ocorrer uma nova atividade de acesso.

O PortCls também se registra na estrutura de energia do Windows (PoFx) para que o plug-in do mecanismo de energia do sistema (PEP) possa ser notificado sobre alterações no estado de energia do dispositivo de áudio. Essas notificações permitem que o PEP saiba quando pode desligar com segurança relógios e trilhas de energia que podem ser compartilhados entre as unidades de processamento de áudio e outros blocos de função do SoC.

Recomendamos que, quando o subsistema de áudio não estiver sendo usado, ele fique em um estado de suspensão em que um total de menos de um miliwatt seja consumido pelo subsistema de áudio. Esse total inclui a energia consumida pelas unidades de processamento de áudio, o codec fora do SoC e circuitos adicionais de áudio (por exemplo, amplificadores para alto-falantes e fones de ouvido).

Topologia de hardware do subsistema de áudio

O subsistema de áudio é composto por vários componentes dentro e fora do SoC, mas é apresentado ao Windows como um único dispositivo no namespace de ACPI.

As unidades de processamento de áudio estão localizadas no SoC. Os SoCs de diferentes fornecedores têm unidades de processamento de áudio que variam em termos de capacidade, consumo de energia e desempenho. As unidades de processamento de áudio executam o descarregamento de áudio; elas processam fluxos de áudio (por exemplo, misturando e aplicando efeitos de áudio) sem usar o processador principal. No caso da reprodução de áudio que não é sensível à latência, o descarregamento de áudio do processador principal é a opção preferencial, pois as unidades de processamento de áudio usam menos energia do que o processador principal.

Para obter mais informações sobre áudio descarregado, confira Processamento de áudio descarregado por hardware.

O sistema também inclui um codec de áudio fora do SoC que converte o fluxo de áudio digital em saída analógica para acionar os alto-falantes integrados ou os fones de ouvido externos. O codec pode incluir amplificadores analógicos integrados para alto-falantes e fones de ouvido. Amplificadores dedicados podem ser usados em vez disso. Um codec típico tem as seguintes conexões com a unidade de processamento de áudio dentro do SoC:

• Interface de áudio digital (I2S ou barramento serial semelhante).
• Interface de controle (normalmente I2C ou barramento serial semelhante).
• Um ou mais pinos GPIO para controlar o circuito de gerenciamento de energia e interromper o SoC quando o estado do codec for alterado.

Essas conexões são mostradas no diagrama de blocos a seguir.

Do ponto de vista do Windows, a unidade de processamento de áudio e o codec de áudio, juntos, compõem o dispositivo de áudio. O dispositivo de áudio deve ser enumerado no namespace ACPI como um único objeto de dispositivo.

Embora o subsistema de áudio deva ser exposto ao Windows por meio de um único driver de áudio, o fornecedor do SoC pode, como alternativa, adotar um modelo de extensão de driver em que o driver de áudio seja decomposto em dois ou mais drivers separados. Por exemplo, o software de controle que gerencia diretamente o codec de áudio pode ser colocado em um driver de codec separado do driver de áudio principal. Em seguida, o driver de áudio principal gerencia indiretamente o codec comunicando-se com o driver de codec. Os detalhes do modelo de extensão de driver estão fora do escopo deste documento e são de propriedade do driver de áudio do fornecedor do SoC. O integrador de sistemas deve trabalhar diretamente com o fornecedor de silício do SoC para implementar esses recursos proprietários no subsistema de áudio.

Modos de gerenciamento de energia

O subsistema de áudio deve aceitar os dois modos de gerenciamento de energia a seguir:

• Um modo ativo, no qual o áudio é ativamente transmitido ao usuário.
• Um modo de suspensão de baixo consumo de energia em que a unidade de processamento de áudio é desligada, o codec SoC desligado é colocado em um modo de baixo consumo de energia e os componentes combinados do subsistema de áudio consomem menos de um miliwatt.

A seguinte tabela descreve esses dois modos de energia.

Mode	Descrição	Estado de energia do dispositivo (Dx)	Média de consumo de energia	Sair da latência para ativo	Mecanismo de transição
Ativo (transmissão por streaming)	As unidades de processamento de áudio transmitem áudio ativamente por streaming, e o codec fornece áudio analógico ou digital para um ponto de extremidade de áudio, como fones de ouvido, alto-falantes integrados ou um dispositivo de saída HDMI remoto.	D0	<= 100 milliwatts (processamento de áudio + codec)	N/D	Transição para D0 iniciada por Portcls. Ocorre quando um aplicativo ou serviço do sistema inicia a transmissão de áudio por streaming.
Modo de suspensão	As unidades de processamento de áudio não transmitem áudio por streaming, e o codec não funciona, exceto para energia em espera suficiente para detectar a inserção ou remoção da tomada.	D3	<= 1 milliwatt (Recomendado.)	<= 35 milissegundos ou <= 300 milissegundos, dependendo do cenário do sistema. (Obrigatório.)	Transição para D3 iniciada por Portcls. Ocorre quando todos os aplicativos concluem a transmissão de áudio por streaming, e o tempo limite ocioso fornecido pelo driver ou pelo sistema expira.

Em alguns projetos de SoC, as unidades de processamento de áudio são blocos multifuncionais compartilhados com decodificação de vídeo e processamento gráfico. Com esses designs, podem existir cenários em que as unidades de processamento de áudio são ligadas quando o áudio não está fazendo uma transmissão ativa por streaming.

Mecanismos de gerenciamento de energia de software

O principal mecanismo de gerenciamento de energia do software para o subsistema de áudio é a detecção de ociosidade em tempo de execução incorporada ao PortCls. A detecção de ociosidade em tempo de execução permite que os PortCls observem a atividade de transmissão de áudio por streaming do aplicativo para determinar quando alternar o dispositivo de áudio entre os modos de energia ativo e de suspensão. O PortCls também permite um mecanismo de extensão proprietário entre o driver de áudio e o PEP (plug-in do mecanismo de energia) disponibilizado pelo fornecedor do SoC para gerenciar o estado de desempenho das unidades de processamento de áudio.

Detecção ociosidade no tempo de execução

Os componentes no subsistema de áudio entram no modo de suspensão de baixo consumo de energia depois que o subsistema de áudio fica ocioso por determinado intervalo de tempo limite especificado.

O driver de áudio disponibilizado pelo fornecedor do SoC deve registrar as duas configurações padrão de tempo limite ocioso a seguir:

• PerformanceIdleTime: use esse intervalo de tempo limite quando a plataforma de hardware estiver conectada à alimentação CA.
• ConservationIdleTime: use esse intervalo de tempo limite quando a plataforma estiver funcionando com energia da bateria.

As configurações de tempo limite ocioso são armazenadas nas entradas do registro localizadas na chave de registro das Configurações de energia. Para obter mais informações, confira Implementação do temporizador de inatividade de classe de dispositivo de áudio.

As seguintes diretivas de .inf devem ser usadas para definir os tempos limite de PerformanceIdleTime e de ConservationIdleTime, ambos de um segundo:

[MyAudioDevice.AddReg]
HKR,PowerSettings,ConservationIdleTime,1,01,00,00,00
HKR,PowerSettings,PerformanceIdleTime,1,01,00,00,00
HKR,PowerSettings,IdlePowerState,1,03,00,00,00

O PortCls colabora com o gerenciador de energia de kernel do Windows para alternar automaticamente entre os valores de tempo limite de PerformanceIdleTime e ConservationIdleTime conforme a plataforma faz a transição entre a energia CA e a energia da bateria.

Quando o sistema está em modo de espera conectado (ou seja, com a tela desligada), e a reprodução de áudio não iniciada, o PortCls sempre usa um tempo limite ocioso de um segundo, independentemente da configuração de tempo limite especificada pelo driver do adaptador no arquivo .inf.

O driver de áudio fornecido pelo fornecedor do SoC também deve registrar uma configuração IdlePowerState para especificar o estado de energia para o qual fazer a transição quando o tempo limite ocioso expirar. Em todas as plataformas de espera conectadas, os drivers de áudio devem registrar D3 como o estado de energia no qual ingressar quando ocorrer um tempo limite ocioso. Para especificar o estado D3, a diretiva AddReg no exemplo anterior define o valor de IdlePowerState como 03.

Quando o tempo limite ocioso expira, o PortCls chama o método IAdapterPowerManagement3::PowerChangeState3 do driver para preparar o dispositivo de áudio para entrar no modo de suspensão de baixo consumo de energia (NewPowerState = PowerDeviceD3). O driver de áudio deve salvar o contexto para a unidade de processamento de áudio e colocar o codec em um modo de suspensão de baixo consumo de energia que consome menos de um miliwatt, em média. No modo de suspensão de baixo consumo de energia, o codec deve continuar tendo energia suficiente para detectar a inserção/remoção da tomada de áudio e gerar uma interrupção acionada por nível para o processador principal no SoC.

Quando a reprodução de áudio é necessária devido ao streaming de aplicativos, geração de som do sistema ou notificação auditiva durante o modo de espera conectado, o PortCls chama o método PowerChangeState3 do driver para pedir para o driver configurar o dispositivo de áudio para funcionar no estado de energia ativo (D0) (NewPowerState = PowerDeviceD0). O driver de áudio deve restaurar o contexto da unidade de processamento de áudio e reativar o codec.

O PortCls chama o método IAdapterPowerManagement3::D3ExitLatencyChanged do driver para notificar o driver de uma alteração na latência máxima que pode ser tolerada para transições do estado de suspensão (D3) para o estado ativo (D0). O PortCls chama o método D3ExitLatencyChanged do driver para definir a latência máxima para 35 millissegundos ou 300 milissegundos. O driver de áudio deve respeitar a tolerância de latência máxima e não entrar em um estado de baixo consumo de energia que exija uma latência de retomada maior do que o valor especificado pelo PortCls no método D3ExitLatencyChanged.

Gerenciamento de energia do codec

O driver de áudio fornecido pelo fornecedor do SoC também é responsável pela configuração e pelo gerenciamento de energia do codec de áudio fora do SoC. O driver normalmente controla o codec de áudio por meio de uma conexão I²C ou de outro barramento periférico simples (SPB) do SoC. O driver também deve lidar com interrupções do dispositivo de codec.

O driver de áudio deve fazer a transição do codec para um modo de suspensão de baixo consumo de energia quando o subsistema de áudio entra no estado D3 (suspensão).

O driver de áudio deve fazer a transição do codec para um modo de energia ativa quando o subsistema de áudio entra no estado D0 (ativo).

Estrutura de energia do Windows (PoFx) e plug-in do mecanismo de energia (PEP)

O PortCls se registra na estrutura de gerenciamento de energia do Windows para que o PEP disponibilizado pelo fornecedor de SoC seja notificado das transições de dispositivo de áudio entre os modos de energia ativo (D0) e de suspensão (D3). Em muitos projetos de SoC, o relógio e as trilhas de energia das unidades de processamento de áudio são compartilhados com outros blocos funcionais no SoC. O PEP disponibilizado pelo fornecedor do SoC conhece as topologias de relógio e energia específicas do SoC e toma as medidas apropriadas para interromper os relógios ou desligar as trilhas de energia associadas à unidade de processamento de áudio quando está no modo de suspensão.

Além disso, o PortCls oferece suporte a um mecanismo privado chamado compartilhamento de contexto que permite que o driver de áudio se comunique diretamente com o PEP para executar o gerenciamento de energia refinado. Por exemplo, um driver de áudio pode usar o compartilhamento de contexto para informar ao PEP o tipo de conteúdo de fluxo de áudio atual e a taxa de bits. O PEP usa essas informações para dimensionar a frequência de relógio da unidade de processamento de áudio até o mínimo necessário para processar o fluxo de áudio atual sem falhas.

A interface de compartilhamento de contexto é definida como um buffer de entrada/saída simples com um identificador GUID, além de ser semelhante a outras interfaces de gerenciamento de energia extensíveis do Windows. Para obter mais informações sobre o compartilhamento de contexto entre o driver de miniporta e o PEP, consulte Compartilhamento de contexto PEP privado do PortCls.

Configuração de energia de hardware com suporte

Em plataformas de espera conectadas, o Windows oferece suporte a uma única configuração de gerenciamento de energia de hardware para o subsistema de áudio.

Na configuração esperada, as unidades de processamento de áudio estão localizadas no SoC, e o codec de áudio externo é conectado ao SoC por meio de uma interface de áudio digital compatível com SoC, um barramento periférico simples (SPB), como I²C, e um ou mais pinos de GPIO. Recomendamos que o codec de áudio e a lógica externa consumam no máximo um miliwatt no modo de energia de suspensão.

O diagrama de blocos a seguir mostra a configuração de hardware esperada, a pilha de driver de dispositivo de áudio e os componentes de modo de usuário.

O subsistema de áudio pode ter componentes localizados por trás do codec que não são visíveis para o sistema operacional e seus drivers. Por exemplo, esses componentes podem incluir amplificadores para os alto-falantes e fones de ouvido. Esses componentes são específicos da plataforma e podem ser selecionados pelo integrador de sistemas dentro dos requisitos descritos como parte do programa de Certificação do Windows.

O integrador de sistemas deve enumerar o dispositivo de áudio de SoC na raiz da hierarquia de namespace APCI. Todos os recursos de memória, E/S, GPIO e I²C (ou outro SPB) necessários para a unidade de processamento de áudio e o codec externo devem ser listados no objeto _CRS, no dispositivo no namespace. O integrador de sistemas e o desenvolvedor de firmware da ACPI devem se comunicar com o desenvolvedor do driver de áudio para entender as convenções para solicitar recursos de hardware, como pinos GPIO. Por exemplo, um driver que recebe dois recursos de GPIO distingue entre eles com base na ordem em que eles aparecem na lista de recursos. Para obter mais informações, confira Recursos de hardware com base em GPIO.

Embora o driver ACPI (Acpi.sys) possa observar as transições ativa (D0) e de suspensão (D3) à medida que os IRPs de energia do dispositivo fluem pela pilha de áudio, o integrador do sistema não deve descrever o codec de áudio como parte de um recurso de energia ou usar os métodos de controle ACPI _PS0 e _PS3 para alterar o estado de energia do codec. No modo de suspensão, o codec deve operar com potência suficientemente baixa para poder permanecer ligado o tempo todo para detectar a inserção e remoção da entrada.

O codec de áudio e os amplificadores externos devem ser colocados em uma trilha de energia que esteja sempre ligada, exceto quando o sistema estiver no estado de desligamento ACPI (S5). Os pinos GPIO podem ser usados para ativar ou desativar os amplificadores sob demanda. Os amplificadores podem ser controlados usando pinos GPIO do codec ou do SoC.

Um requisito fundamental é que o próprio codec permaneça ligado o tempo todo, mesmo quando estiver em um modo de suspensão de baixo consumo de energia, de modo que a inserção e a remoção da entrada possam ser detectadas. O codec deve gerar uma interrupção que possa despertar o SoC de seu estado ocioso mais profundo para lidar com a inserção e a remoção de fones de ouvido.

Questões de ativação (detecção de fone de ouvido e entrada de microfone)

O subsistema de áudio deve lidar com alterações no estado do dispositivo de saída de áudio que podem ocorrer a qualquer momento. As alterações de estado do dispositivo de áudio mais comuns são a inserção de um dispositivo de saída na entrada de fone de ouvido integrada e a remoção deste dispositivo da entrada. A inserção e a remoção da tomada também devem ser detectadas para outras portas de áudio conectadas, incluindo portas de microfone e sinal digital.

A pilha de áudio deve ser capaz de detectar a inserção e a remoção da tomada a qualquer momento. A linha de interrupção do codec de áudio deve ser conectada a um pino GPIO que esteja sempre ligado e podendo despertar o SoC do estado ocioso mais profundo. A detecção de tomada permite que o Windows mantenha informações atualizadas sobre os dispositivos de entrada e saída de áudio em tempo real, incluindo todos os momentos em que o sistema está em modo de espera conectado. Por exemplo, o Windows é imediatamente notificado quando o usuário insere um plugue na tomada de fones de ouvido. Em resposta a essa notificação, quaisquer futuros sons de alerta de notificação de espera conectados são roteados para os fones de ouvido em vez dos alto-falantes integrados da plataforma.

Como descrito anteriormente, o firmware do sistema atribui um conjunto de recursos de hardware ao dispositivo de áudio. Esses recursos são descritos no objeto ACPI _CRS, e o sistema operacional passa uma lista desses recursos para o driver de áudio. Esta lista de recursos inclui todas as interrupções GPIO usadas para detectar alterações de estado no dispositivo de saída de áudio (por exemplo, inserção de fone de ouvido). Essas interrupções devem ser marcadas no firmware ACPI do sistema como fontes de ativação. O driver de áudio deve adicionar manipuladores de interrupção para cada uma dessas interrupções de ativação. Os manipuladores de interrupção devem atualizar o estado do dispositivo de áudio, do codec de áudio e do driver de áudio, conforme apropriado, de acordo com o qual a interrupção foi sinalizada.

A ordem dos recursos no objeto _CRS é baseada em uma convenção específica do dispositivo definida pelo desenvolvedor do driver de áudio. Por exemplo, se o driver receber dois recursos de interrupção, o driver distinguirá entre eles com base na ordem em que eles ocorrem na lista de recursos. O desenvolvedor do firmware ACPI deve usar a mesma ordem para descrever esses recursos no firmware ACPI.

Vários subsistemas de hardware, firmware e software devem colaborar para que a detecção de inserção e remoção de conector de áudio funcione corretamente. O integrador de sistemas e o desenvolvedor de drivers de áudio devem seguir as diretrizes de implementação abaixo:

Hardware e SoC

• O hardware do codec de áudio deverá detectar eventos de inserção e remoção de fones de ouvido, microfone e outras tomadas sempre que o sistema estiver ligado, inclusive quando o sistema estiver em modo de espera conectado.
• O hardware do codec de áudio deve ser capaz de detectar a inserção e a remoção da tomada enquanto consome muito pouca energia (menos de um miliwatt, em média).
• A interrupção do codec de áudio deve ser conectada a um pino GPIO no SoC capaz de despertar o SoC do estado de energia mais profundo.

Firmware ACPI

• O dispositivo de áudio deve ser descrito no namespace ACPI.
• As linhas GPIO usadas para detectar a inserção da tomada devem ser descritas pelo firmware ACPI como interrupções exclusivas e de ativação. Use a macro do descritor GpioInt e defina o argumento Shared como ExclusiveAndWake.
• Os recursos de hardware do dispositivo de áudio devem ser listados na ordem esperada pelo driver de áudio.

Software de driver de áudio

• O driver de áudio deve conectar um manipulador de interrupção às interrupções de ativação GPIO.
• Quando o driver de áudio lida com a interrupção, ele avalia o estado dos dispositivos de entrada/saída de áudio e executa as ações apropriadas.

Teste e validação

Os integradores de sistemas podem usar o WPA (Windows Performance Analyzer) para verificar se o dispositivo de áudio executa corretamente o gerenciamento de energia ociosa em tempo de execução e as transições conforme esperado entre os estados ativo (D0) e de suspensão (D3). O WPA está disponível no site do Microsoft Connect. Entre em contato com o representante da Microsoft para obter assistência na obtenção de WPA e as extensões de gerenciamento de energia do WPA. O integrador de sistemas também deve obter o pacote de ferramentas de análise de gerenciamento de energia do WPA. Esse pacote inclui extensões para o WPA que permitem a análise de gerenciamento de energia do sistema.

O WPA depende da instrumentação ETW (Rastreamento de Eventos para Windows) incorporada ao kernel do Windows e a outros componentes do Windows, incluindo PortCls. Para usar o rastreamento ETW, um conjunto de provedores de rastreamento é habilitado, e seus eventos são registrados em um arquivo de log enquanto um cenário de teste é executado. Quando o cenário for concluído, os provedores de rastreamento serão interrompidos. O WPA permite o pós-processamento e a análise visual do arquivo de log gerado pelo cenário em teste.

Em um sistema que tenha o WPA instalado, um conjunto de comandos pode ser usado para coletar a instrumentação de gerenciamento de energia para validar o gerenciamento de energia do dispositivo de áudio. A ferramenta Xperf.exe é instalada na pasta \%Program Files%\Windows Kits\8.0\Windows Performance Analyzer.

Para iniciar o rastreamento de ETW de gerenciamento de energia, abra uma janela do prompt de comando como Administrador, altere para o diretório que contém o WPA e execute os seguintes comandos:

>xperf -start powertracesession -on Microsoft-Windows-Kernel-Power
>xperf -capturestate powertracesession Microsoft-Windows-Kernel-Power

Esses comandos instruem o Windows a habilitar o provedor de eventos do ETW Microsoft-Windows-Kernel-Energia e capturar o estado inicial dos eventos do provedor Microsoft-Windows-Kernel-Power.

Depois que o rastreamento do ETW for iniciado, o desenvolvedor deverá exercitar cenários do sistema para verificar se o dispositivo de áudio faz a transição correta entre os modos de energia ativo (D0) e de suspensão (D3). O desenvolvedor deve validar o dispositivo de áudio nos seguintes cenários:

• Inicie um aplicativo que faz a transição do dispositivo de áudio do estado D3 para o estado D0.
• Um segundo depois que todos os aplicativos de áudio são fechados, o dispositivo de áudio faz a transição do estado D0 para o estado D3.
• Quando o sistema está em modo de espera conectado, o dispositivo de áudio permanece no estado D3.
• Quando uma notificação auditiva é gerada durante o modo de espera conectado, o dispositivo de áudio faz a transição de D3 para D0, reproduz áudio e retorna para D3 após um segundo.

Depois que esses cenários de teste forem concluídos, use o seguinte comando stop ETW trace collection:

>xperf -stop powertracesession -d trace.etl

Use WPA para abrir o arquivo Trace.etl resultante. Para iniciar o WPA a partir da linha de comando, digite o comando Wpa.exe.

Na ferramenta WPA, selecione o gráfico Device Dstate na lista Explorador do Graph, e a seguinte exibição aparecerá.

Nessa exibição, um dispositivo é identificado pelo nome ACPI (por exemplo, \_SB.AUDI) ou o caminho da instância do dispositivo (por exemplo, ACPI\MSFT0731\4%ffff367&2). O nome ACPI e o caminho da instância do dispositivo estão listados na tabela de resumo do gráfico Device Dstate.

Para exibir as transições de estado D feitas pelo dispositivo de áudio, localize o nome do dispositivo na tabela de resumo, clique com o botão direito do mouse no nome e escolha Filtrar para seleção. O gráfico resultante mostra apenas as transições de estado D do dispositivo de áudio, conforme mostrado na captura de tela a seguir.

Este rastreamento de exemplo mostra que o dispositivo de áudio estava no estado D3 (indicado pela coordenada 3 no eixo vertical) durante todo o rastreamento, exceto por um período de cinco segundos a aproximadamente 290 segundos a partir do início do rastreamento.

Lista de verificação de gerenciamento de energia

Os integradores de sistemas e os fornecedores de SoC devem usar a lista de verificação a seguir para garantir que o design de gerenciamento de energia do subsistema de áudio seja compatível com o Windows 8.1.

• O integrador de sistemas deve trabalhar em estreita colaboração com o fornecedor do SoC para integrar dispositivos de subsistema de áudio.

• O driver de áudio desenvolvido pelo fornecedor do SoC deve fazer o seguinte:

  • Defina tempos limite de ociosidade no tempo de execução para quando o sistema estiver funcionando com energia CA e bateria. O driver de áudio deve definir o valor PerformanceIdleTime e o valor ConservationIdleTime como um segundo.

  • Defina o valor IdlePowerState como D3.

  • No arquivo .inf do driver de áudio, defina IdlePowerState, PerformanceIdleTime e ConservationIdleTime com os seguintes valores:

    [MyAudioDevice.AddReg]
    HKR,PowerSettings,ConservationIdleTime,1,01,00,00,00
    HKR,PowerSettings,PerformanceIdleTime,1,01,00,00,00
    HKR,PowerSettings,IdlePowerState,1,03,00,00,00
    

  • O driver de áudio deve salvar todo o contexto da unidade de processamento de áudio e colocar o codec em um modo de suspensão de baixo consumo de energia quando PortCls chama o método IAdapterPowerManagement3::PowerChangeState3 do driver com um estado de energia do dispositivo de D3.

  • O driver de áudio deve restaurar todo o contexto da unidade de processamento de áudio e reativar o codec quando PortCls chama o método PowerChangeState3 com um estado de energia do dispositivo de D0.

  • O driver de áudio não deve usar estados de energia que violem o requisito de latência de saída D3 fornecido por PortCls no método IAdapterPowerManagement3:D3ExitLatencyChanged.

  • O driver de áudio deve lidar com a configuração e o gerenciamento de energia do codec externo.

  • O driver de áudio deve lidar com interrupções acionadas por nível do codec externo quando o codec detecta a inserção ou remoção da tomada.

• O fornecedor do SoC deve fornecer um plug-in do mecanismo de energia (PEP) que faça o seguinte:

  • Coloca as unidades de processamento de áudio em um estado de baixo consumo de energia quando o driver de áudio faz a transição para o modo de suspensão (D3).
  • Liga qualquer relógio e trilhas de energia necessários para as unidades de processamento de áudio quando o driver de áudio faz a transição para o modo de energia ativo (D0).
  • Dimensiona corretamente o relógio e a tensão fornecidos à unidade de processamento de áudio de acordo com o nível necessário de atividade de processamento, que depende do formato de áudio, do tipo de conteúdo e da taxa de bits.

• Para desenvolver a plataforma de hardware e firmware para o subsistema de áudio, o integrador de sistemas deve fazer o seguinte:

  • Usar um codec que, no modo de suspensão, consuma menos de um miliwatt, mas ainda possa detectar eventos de inserção e remoção de conector.
  • Colocar o codec em um trilho de alimentação do sistema que esteja ligado o tempo todo, exceto quando o sistema estiver no estado de desligamento ACPI (S5).
  • Projetar o firmware ACPI para enumerar o subsistema de áudio como um único dispositivo na raiz da hierarquia de namespace ACPI.
  • Determinar as convenções de ordenação de recursos de memória, interrupção, E/S, GPIO e I²C esperadas pelo driver de áudio e verifique se os recursos estão listados na mesma ordem no objeto _CRS ACPI.

• Para testar e validar o gerenciamento de energia do subsistema de áudio, o integrador de sistemas deve fazer o seguinte:

  • Verifique se o driver de áudio faz a transição para o estado de energia D3 quando nenhum aplicativo está usando o subsistema de áudio ou gerando áudio para o usuário.
  • Quando estiver em espera a partir da ociosidade, verifique se o driver de áudio permanece no estado de energia D0 ativo quando um aplicativo ou o sistema está gerando áudio, inclusive durante a reprodução de áudio quando a tela está desligada.
  • Quando estiver em espera a partir da entrada explícita (pressionamento do botão liga/desliga, verifique se todos os fluxos de áudio estão fechados do sistema operacional e se o driver de áudio faz a transição para o estado de energia D3 quando um aplicativo ou o sistema está gerando áudio) (novo no OS 24H2).
  • Verifique se a reprodução de áudio é executada sem falhas e erros usando os testes fornecidos no HLK (Hardware Lab Kit) do Windows.
  • Verifique se a detecção de conector funciona corretamente quando o sistema está em modo de espera conectado e se o áudio é roteado corretamente para os fones de ouvido ou alto-falantes quando o usuário insere o plugue no conector de fones de ouvido ou remove o plugue do conector.
  • Quantifique a energia consumida pela unidade de processamento de áudio, pelo codec externo e por qualquer circuito de amplificação analógica adicional. Certifique-se de que todo o subsistema de áudio consuma menos de um miliwatt quando estiver no estado de suspensão (D3) de energia.