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

Todo computador Windows tem um subsistema de áudio que permite que o usuário ouça e grave som de alta qualidade em tempo real. Uma plataforma de hardware que dá suporte ao modelo de energia em espera conectado normalmente é criada em torno de um circuito integrado do System on a Chip (SoC) que apresenta unidades internas de processamento de áudio de baixa potência.

As unidades de processamento de áudio descarregam o processamento de áudio do processador main (ou processadores) no SoC. Como essas unidades podem processar dados de áudio sem usar o processador main, o usuário pode continuar a escutar áudio mesmo depois que o processador main entrar em um estado de baixa energia para conservar a energia da bateria.

Este vídeo mostra como usar o Windows Performance Analyzer (WPA) para verificar se um computador entra no estado de baixa potência durante a reprodução de áudio desativada da tela (também conhecida como áudio de baixa potência ou LPA).

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

Visão geral do subsistema de áudio

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

• Converte fluxos digitais decodificados em sons analógicos.
• Unidades de alto-falantes internos.
• Dirige fones de ouvido analógicos anexados externamente.

Assim como acontece com um subsistema de câmera, o subsistema de áudio apresenta componentes on-SoC e off-SoC. No entanto, o Windows espera que um único driver de áudio gerencie os mecanismos de processamento de áudio no SoC e o codec off-SoC. Esse driver de áudio único é responsável por gerenciar os componentes integrados ao SoC e os componentes fora do SoC que podem ser selecionados pelo integrador do sistema. Portanto, o integrador do sistema deve trabalhar em estreita colaboração com o fornecedor de silício do 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 do sistema Portcls, Portcls.sys, que é um componente de caixa de entrada do Windows.

Em comparação com outras classes de dispositivo, o subsistema de áudio é exclusivo na maneira como faz o gerenciamento de energia quando a plataforma está no estado de energia em espera conectado (ou seja, quando a tela é desativada). Quando a plataforma está conectada em espera, o sistema pode gerar sons de áudio para notificar o usuário de eventos (por exemplo, a chegada de um novo email) em tempo real. Além disso, o usuário pode desativar a exibição do sistema e continuar a escutar o áudio que está sendo reproduzido por um aplicativo. Esses recursos não podem ser obtidos por uma estratégia simples de gerenciamento de energia na qual o subsistema de áudio deve ser desativado quando o sistema está em espera conectado. Em vez disso, o gerenciamento de energia do subsistema de áudio deve ser executado em tempo de execução ocioso (para que ele seja ativado somente quando necessário) em todos os momentos, exceto quando o sistema estiver no estado de Desligamento de ACPI (S5).

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

PortCls também se registra com a PoFx ( Estrutura de Energia do Windows ) para que o PEP (plug-in do power engine do sistema) possa ser notificado sobre alterações no estado de energia do dispositivo de áudio. Essas notificações permitem que o PEP saiba quando pode desativar com segurança relógios e trilhos de alimentação 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 deve estar em um estado de suspensão no qual um total de menos de um miliwatt é consumido pelo subsistema de áudio. Esse total inclui a energia consumida pelas unidades de processamento de áudio, o codec off-SoC e qualquer circuito de áudio adicional (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 on-SoC e off-SoC, mas é apresentado ao Windows como um único dispositivo no namespace ACPI.

As unidades de processamento de áudio estão localizadas no SoC. SoCs de diferentes fornecedores têm unidades de processamento de áudio que variam em seus recursos, consumo de energia e desempenho. As unidades de processamento de áudio executam o descarregamento de áudio— processam fluxos de áudio (por exemplo, misturando e aplicando efeitos de áudio) sem usar o processador main. Para reprodução de áudio que não diferencia latência, é preferível descarregar áudio do processador main porque as unidades de processamento de áudio usam menos energia do que o processador main.

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

O sistema também inclui um codec de áudio off-SoC que converte o fluxo de áudio digital em saída analógica para conduzir alto-falantes internos ou fones de ouvido externos. O codec pode incluir amplificadores analógicos integrados para alto-falantes e fones de ouvido. Ou amplificadores discretos podem ser usados. Um codec típico tem as seguintes conexões com a unidade de processamento de áudio no SoC:

• Uma interface de áudio digital (I2S ou um barramento serial semelhante).
• Uma interface de controle (normalmente I2C ou barramento serial semelhante).
• Um ou mais pinos de 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 bloco 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 opção, adotar um modelo de extensão de driver no qual o driver de áudio é 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 main. O driver de áudio main gerencia indiretamente o codec comunicando-se com o driver codec. Os detalhes desse modelo de extensão de driver estão fora do escopo deste documento e são proprietários do driver de áudio do fornecedor do SoC. O integrador do sistema 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 dar suporte aos dois seguintes modos de gerenciamento de energia:

• Um modo ativo no qual o áudio está sendo transmitido ativamente para o usuário.
• Um modo de suspensão de baixa potência no qual a unidade de processamento de áudio está desativada, o codec off-SoC é colocado em um modo de baixa potência e os componentes de subsistema de áudio combinados consomem menos de um miliwatt.

A tabela a seguir 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 (streaming)	As unidades de processamento de áudio estão transmitindo áudio ativamente e o codec está fornecendo áudio analógico ou digital para um ponto de extremidade de áudio , como fones de ouvido, alto-falantes internos ou um dispositivo de saída HDMI remoto.	D0	<= 100 miliwatts (processamento de áudio + codec)	N/D	Transição para D0 iniciada por Portcls. Ocorre quando um aplicativo ou serviço do sistema inicia o streaming de áudio.
Modo de suspensão	As unidades de processamento de áudio não estão transmitindo áudio e o codec não está operacional, exceto por energia em espera suficiente para detectar a inserção ou remoção de tomadas.	D3	<= 1 miliwatt (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 terminam o streaming de áudio e o tempo limite ocioso fornecido pelo driver ou fornecido pelo sistema expira.

Em alguns designs 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, pode haver cenários em que as unidades de processamento de áudio são ativadas quando o áudio não está sendo transmitido ativamente.

Mecanismos de gerenciamento de energia de software

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

Detecção ociosa em tempo de execução

Os componentes no subsistema de áudio entram no modo de suspensão de baixa potência depois que o subsistema de áudio fica ocioso por algum intervalo de tempo limite especificado.

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

• PerformanceIdleTime – use esse intervalo de tempo limite quando a plataforma de hardware estiver conectada à energia ac.
• ConservationIdleTime – use esse intervalo de tempo limite quando a plataforma estiver em execução na energia da bateria.

As configurações de tempo limite ocioso são armazenadas em entradas do Registro localizadas sob a chave do Registro PowerSettings do driver de áudio. Para obter mais informações, consulte Implementação do temporizador de inatividade da classe de dispositivo de áudio.

As seguintes diretivas .inf devem ser usadas para definir um tempo limite de PerformanceIdleTime de um segundo e um tempo limite de ConservationIdleTime 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 do kernel do Windows para alternar automaticamente entre os valores de tempo limite PerformanceIdleTime e ConservationIdleTime à medida que a plataforma faz a transição entre a energia ac e a energia da bateria.

Quando o sistema está em espera conectado (ou seja, com a tela desativada) e a reprodução de áudio não é iniciada, PortCls sempre usa um tempo limite ocioso de um segundo, independentemente da configuração de tempo limite que o driver do adaptador especifica em seu 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 em espera conectadas, os drivers de áudio devem registrar D3 como o estado de energia para entrar quando ocorrer um tempo limite ocioso. Para especificar o estado D3, a diretiva AddReg no exemplo anterior define o valor IdlePowerState como 03.

Quando o tempo limite ocioso expira, PortCls chama o método IAdapterPowerManagement3::P owerChangeState3 do driver para instruir o driver a preparar o dispositivo de áudio para entrar no modo de suspensão de baixa potência (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 baixa potência que consome menos de um miliwatt, em média. No modo de suspensão de baixa potência, o codec deve continuar a ter energia suficiente para detectar a inserção/remoção da tomada de áudio e gerar uma interrupção disparada por nível para o processador main no SoC.

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

PortCls chama o método IAdapterPowerManagement3::D 3ExitLatencyChanged do driver de áudio 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). PortCls chama o método D3ExitLatencyChanged do driver de áudio para definir a latência máxima como 35 milissegundos ou 300 milissegundos. O driver de áudio deve respeitar a tolerância máxima de latência e não inserir um estado de baixa potência que exija uma latência de retomada maior que o valor especificado por PortCls no método D3ExitLatencyChanged .

Gerenciamento de energia do Codec

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

O driver de áudio deve fazer a transição do codec para um modo de suspensão de baixa potência quando o subsistema de áudio entra no estado D3 (suspensão).

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

PoFx (Windows Power Framework) e PEP (plug-in do power engine)

PortCls registra-se com aestrutura de gerenciamento de energia do Windows para que o PEP fornecido pelo fornecedor de SoC seja notificado sobre transições de dispositivo de áudio entre os modos de energia ativo (D0) e suspensão (D3). Em muitos designs soc, o relógio e os trilhos de alimentação para as unidades de processamento de áudio são compartilhados com outros blocos funcionais on-SoC. O PEP fornecido pelo fornecedor do SoC está ciente das topologias de energia e do relógio específicos do SoC e executa a ação apropriada para parar relógios ou desativar os trilhos de alimentação associados à unidade de processamento de áudio quando ela estiver no modo de suspensão.

Além disso, o PortCls dá 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 o PEP sobre 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 do relógio da unidade de processamento de áudio para 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 e é semelhante a outras interfaces extensíveis de gerenciamento de energia do Windows. Para obter mais informações sobre o compartilhamento de contexto entre o driver de miniporto e o PEP, consulte PortCls Private PEP Context Sharing.

Configuração de energia de hardware com suporte

Em plataformas em espera conectadas, o Windows dá 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 está conectado ao SoC por meio de uma interface de áudio digital compatível com SoC, um SPB ( barramento periférico simples ), como I²C, e um ou mais pinos GPIO. Recomendamos que o codec de áudio e a lógica externa não consumam mais de um miliwatt no modo de energia de suspensão.

O diagrama de bloco a seguir mostra a configuração de hardware esperada, a pilha de driver de dispositivo de áudio e os componentes do 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 alto-falantes e fones de ouvido. Esses componentes são específicos da plataforma e podem ser selecionados pelo integrador do sistema dentro dos requisitos descritos como parte do programa de certificação do Windows.

O integrador do sistema deve enumerar o dispositivo de áudio SoC na raiz da hierarquia do namespace APCI. Todos os recursos de memória, E/S, GPIO e I²C (ou outros 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 do sistema e o desenvolvedor de firmware 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 gpio distingue entre eles com base na ordem em que eles aparecem na lista de recursos. Para obter mais informações, consulte Recursos de hardware baseados em GPIO.

Embora o driver ACPI (Acpi.sys) possa observar as transições ativas (D0) e 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, espera-se que o codec opere com potência suficientemente baixa para que possa ser deixado ligado o tempo todo para detectar a inserção e a remoção da tomada.

O codec de áudio e todos os amplificadores externos devem ser colocados em um trilho de alimentação que é sempre ligado, exceto quando o sistema está no estado de Desligamento de ACPI (S5). Os pinos GPIO podem ser usados para habilitar ou desabilitar 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 está em um modo de suspensão de baixa potência , para que a inserção e a remoção da tomada possam ser detectadas. O codec deve gerar uma interrupção que possa ativar o SoC de seu estado ocioso mais profundo para lidar com a inserção e remoção da tomada do fone de ouvido.

Preocupações de ativação (detecção de conector de fone de ouvido e 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 mais comuns do dispositivo de áudio são a inserção de um dispositivo de saída na tomada interna do fone de ouvido e a remoção desse dispositivo da tomada. A inserção e a remoção da tomada também devem ser detectadas para outras portas de áudio anexadas, incluindo portas de microfone e sinal digital.

Em todos os momentos, a pilha de áudio deve ser capaz de detectar a inserção e a remoção da tomada. A linha de interrupção do codec de áudio deve ser conectada a um pino GPIO que é sempre ligado e sempre capaz de ativar o SoC de seu 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 todas as vezes em que o sistema está em espera conectado. Por exemplo, o Windows é notificado imediatamente quando o usuário insere um plug-in na tomada de fones de ouvido. Em resposta a essa notificação, quaisquer sons de alerta de notificação em espera conectados futuros são roteados para os fones de ouvido em vez de para os alto-falantes internos da plataforma.

Conforme descrito anteriormente, o firmware do sistema atribui um conjunto de recursos de hardware ao dispositivo de áudio. Esses recursos são descritos no objeto _CRS ACPI e o sistema operacional passa uma lista desses recursos para o driver de áudio. Essa lista de recursos inclui todas as interrupções gpio que são 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. Espera-se que o driver de áudio adicione 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, com base em qual interrupção foi sinalizada.

A ordenação de recursos no objeto _CRS baseia-se 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 de firmware acpi deve usar a mesma ordenação para descrever esses recursos no firmware acpi.

Vários subsistemas de hardware, firmware e software devem colaborar para fazer com que a detecção de remoção e inserção de tomada de áudio funcione corretamente. O integrador do sistema e o desenvolvedor do driver de áudio devem seguir as seguintes diretrizes de implementação:

Hardware e SoC

• O hardware do codec de áudio deve detectar o fone de ouvido, o microfone e outros eventos de inserção e remoção de tomadas em todos os momentos em que o sistema está ligado, inclusive quando o sistema está em 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 uma média de miliwatts).
• A interrupção do codec de áudio deve ser conectada a um pino gpio no SoC que é capaz de acordar o SoC de seu 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 de 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 do 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 do sistema 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 o esperado entre os estados ativo (D0) e suspensão (D3). O WPA está disponível no site do Microsoft Connect. Entre em contato com seu representante da Microsoft para obter assistência na obtenção do WPA e das extensões de Gerenciamento de Energia do WPA. O integrador do sistema também deve obter o pacote WPA Power Management Analysis Tools. 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 habilita 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 instrumentação de gerenciamento de energia para validar o gerenciamento de energia do dispositivo de áudio. A ferramenta Xperf.exe é instalada na pasta Performance Analyzer \%Program Files%\Windows Kits\8.0\Windows.

Para iniciar o rastreamento 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 ETW Microsoft-Windows-Kernel-Power e capturar o estado inicial dos eventos do provedor Microsoft-Windows-Kernel-Power.

Depois que o rastreamento ETW for iniciado, o desenvolvedor deverá exercer cenários do sistema para verificar se o dispositivo de áudio faz a transição correta entre os modos de energia ativo (D0) e 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 para D3 do estado D0.
• Quando o sistema está em 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 a seguinte coleção de rastreamento ETW de parada de comando:

>xperf -stop powertracesession -d trace.etl

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

Na ferramenta WPA, selecione o grafo Dstate do Dispositivo na lista Explorer do Graph e a exibição a seguir deve aparecer.

Nessa exibição, um dispositivo é identificado por seu nome ACPI (por exemplo, \_SB. AUDI) ou o caminho da instância do dispositivo (por exemplo, ACPI\MSFT0731\4%ffff367&2). O nome do ACPI e o caminho da instância do dispositivo são listados na tabela de resumo do grafo 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 grafo 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 toda a duração do rastreamento, exceto por um período de cinco segundos a aproximadamente 290 segundos do início do rastreamento.

Lista de verificação de gerenciamento de energia

Os integradores do sistema 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 Windows 8.1.

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

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

  • Defina tempos limite ociosos de tempo de execução para quando o sistema estiver em execução com energia AC e com energia da 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 como 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 baixa potência quando PortCls chamar o método IAdapterPowerManagement3::P owerChangeState3 do driver com um estado de energia do dispositivo D3.

  • O driver de áudio deve restaurar todo o contexto da unidade de processamento de áudio e reabilitar o codec quando PortCls chamar o método PowerChangeState3 do driver com um estado de energia do dispositivo 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 disparadas por nível do codec externo quando o codec detecta a inserção ou remoção de tomada.

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

  • Coloca as unidades de processamento de áudio em um estado de baixa potência quando o driver de áudio faz a transição para o modo de suspensão (D3).
  • Ativa qualquer relógio e trilhos de alimentação 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 para a 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 do sistema deve fazer o seguinte:

  • Use um codec que, no modo de suspensão, consome menos de um miliwatt, mas ainda pode detectar eventos de inserção e remoção de tomadas.
  • Coloque o codec em um power rail do sistema ativado o tempo todo, exceto quando o sistema estiver no estado de Desligamento de ACPI (S5).
  • Crie o firmware ACPI para enumerar o subsistema de áudio como um único dispositivo na raiz da hierarquia de namespace acpi.
  • Determine 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 acpi _CRS.

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

  • Verifique se o driver de áudio faz a transição para o estado de energia D3 quando nenhum aplicativo estiver usando o subsistema de áudio ou gerando áudio para o usuário.
  • Verifique se o driver de áudio faz a transição para o estado de energia ativo (D0) quando um aplicativo ou o sistema está gerando áudio, inclusive durante a reprodução de áudio quando a tela é desativada.
  • Verifique se a reprodução de áudio é executada de maneira livre de falhas e sem erros usando os testes fornecidos no HCK (Windows Certification Test Suite).
  • Verifique se a detecção de tomada funciona corretamente quando o sistema está em espera conectado e se o áudio é roteado corretamente para os fones de ouvido ou alto-falantes quando o usuário insere o plug-in na tomada de fones de ouvido ou remove o plug-in da tomada.
  • Meça a energia consumida pela unidade de processamento de áudio, o codec externo e qualquer circuito de amplificação analógica adicional. Verifique se todo o subsistema de áudio consome menos de um miliwatt quando está no estado de energia de suspensão (D3).