Administración de energía del subsistema de audio para plataformas modernas en espera

Cada PC Windows tiene un subsistema de audio que permite al usuario escuchar y grabar sonido de alta calidad en tiempo real. Normalmente, una plataforma de hardware que admite el modelo de energía en espera conectado se basa en un circuito integrado de sistema en un chip (SoC) que incluye unidades integradas de procesamiento de audio de baja energía.

Las unidades de procesamiento de audio descargan el procesamiento de audio desde los procesadores principales en el SoC. Dado que estas unidades pueden procesar datos de audio sin usar el procesador principal, el usuario puede seguir escuchando audio incluso después de que el procesador principal entre en un estado de baja energía para ahorrar energía de la batería.

En este vídeo se muestra cómo usar Windows Performance Analyzer (WPA) para comprobar que un equipo entra en el estado de baja energía durante la reproducción de audio con la pantalla apagada (también conocido como audio de baja energía o LPA).

En el siguiente artículo se describe la administración de energía del subsistema de audio para las plataformas en espera conectadas. En la siguiente discusión, el término componente en SoC describe un componente integrado en el chip SoC. Un componente fuera de SoC es externo al chip SoC.

Introducción al subsistema de audio

Además de los bloques de función SoC que realizan el procesamiento de audio descargado, cada plataforma en espera conectada incluye un componente fuera de SoC, denominado códec, que hace lo siguiente:

• Traduce secuencias digitales descodificadas en sonidos analógicos.
• Controla los altavoces integrados.
• Controla los auriculares analógicos conectados externamente.

Al igual que con un subsistema de cámara, el subsistema de audio cuenta con componentes en SoC y fuera de SoC. Sin embargo, Windows espera que un único controlador de audio administre los motores de procesamiento de audio en SoC y el códec fuera de SoC. Este único controlador de audio se encarga de administrar los componentes integrados en soC y los componentes fuera de SoC que el integrador del sistema puede seleccionar. Por lo tanto, el integrador del sistema debe trabajar estrechamente con el proveedor de silicio SoC en la integración del subsistema de audio y la administración de energía.

El proveedor de hardware de audio debe implementar el controlador de audio como controlador de minipuerto de clase de puerto (Portcls). El controlador de audio funciona junto con el controlador del sistema Portcls, Portcls.sys, que es un componente de la bandeja de entrada de Windows.

En comparación con otras clases de dispositivos, el subsistema de audio es único en la forma en que realiza la gestión de energía cuando la plataforma está en el estado de energía en espera conectada (es decir, cuando la pantalla está apagada). Cuando la plataforma está en espera conectada, el sistema puede generar sonidos de audio para notificar eventos al usuario (por ejemplo, la llegada de un nuevo correo electrónico) en tiempo real. Además, el usuario puede desactivar la pantalla del sistema y, a continuación, seguir escuchando el audio que reproduce una aplicación. Estas funcionalidades no se pueden lograr mediante una estrategia sencilla de administración de energía en la que el subsistema de audio debe desactivarse cuando el sistema está en espera conectada. En su lugar, la administración de energía del subsistema de audio debe realizarse en tiempo de ejecución (de modo que se active solo cuando sea necesario) en todo momento, excepto cuando el sistema esté en estado de apagado ACPI (S5).

El controlador de audio realiza la administración de energía inactiva en tiempo de ejecución en estrecha cooperación con la infraestructura de audio de Windows y el controlador del sistema PortCls. PortCls supervisa todos los accesos (como accesos de E/S y propiedades) del dispositivo de audio y restablece el temporizador de inactividad en cada acceso. Si el temporizador de inactividad expira, PortCls realiza la transición del dispositivo de audio (con ayuda del controlador de audio) a un estado de suspensión de baja energía (D3). PortCls devuelve el dispositivo de audio al estado activo (D0) en caso de nueva actividad de acceso.

PortCls también se registra con el marco de energía de Windows (PoFx) para que el complemento del motor de energía del sistema (PEP) pueda recibir una notificación de los cambios de estado de energía del dispositivo de audio. Estas notificaciones permiten que el PEP sepa cuándo puede desactivar de forma segura los raíles de reloj y alimentación que podrían compartirse entre las unidades de procesamiento de audio y otros bloques de funciones SoC.

Se recomienda que cuando el subsistema de audio no se esté utilizando, se encuentre en un estado de suspensión en el que el consumo total del subsistema de audio sea inferior a un milivatio. Este total incluye la energía consumida por las unidades de procesamiento de audio, el códec fuera de SoC y cualquier circuito de audio adicional (por ejemplo, amplificadores para altavoces y auriculares).

Topología de hardware del subsistema de audio

El subsistema de audio se compone de varios componentes en SoC y fuera de SoC, pero se presenta a Windows como un único dispositivo en el espacio de nombres ACPI.

Las unidades de procesamiento de audio se encuentran en el SoC. Los SoC de diferentes proveedores tienen unidades de procesamiento de audio que varían en sus capacidades, consumo de energía y rendimiento. Las unidades de procesamiento de audio realizan la descarga de audio, procesan secuencias de audio (por ejemplo, mezclando y aplicando efectos de audio) sin usar el procesador principal. Para la reproducción de audio que no es sensible a la latencia, es preferible descargar el audio del procesador principal porque las unidades de procesamiento de audio utilizan menos energía que el procesador principal.

Para obtener más información sobre el audio descargado, consulte Procesamiento de audio descargado por hardware.

El sistema también incluye un códec de audio fuera de SoC que convierte la secuencia de audio digital en salida analógica para alimentar los altavoces integrados o auriculares externos. El códec puede incluir amplificadores analógicos integrados para altavoces y auriculares. O bien, se pueden usar amplificadores discretos en su lugar. Un códec típico tiene las siguientes conexiones a la unidad de procesamiento de audio en SoC:

• Una interfaz de audio digital (I2S o bus serie similar).
• Una interfaz de control (normalmente I2C o bus serie similar).
• Uno o varios pines de GPIO para controlar los circuitos de administración de energía e interrumpir el SoC cuando cambia el estado del códec.

Estas conexiones se muestran en el siguiente diagrama de bloques.

Desde el punto de vista de Windows, la unidad de procesamiento de audio y el códec de audio forman el dispositivo de audio. El dispositivo de audio debe enumerarse en el espacio de nombres ACPI como un único objeto de dispositivo.

Aunque el subsistema de audio debe exponerse a Windows a través de un único controlador de audio, el proveedor de SoC podría adoptar, como opción, un modelo de extensión de controlador en el que el controlador de audio se descompone en dos o más controladores independientes. Por ejemplo, el software de control que administra directamente el códec de audio puede colocarse en un controlador de códec que sea independiente del controlador de audio principal. Después, el controlador de audio principal administra indirectamente el códec mediante la comunicación con el controlador de códec. Los detalles de este modelo de extensión de controlador están fuera del ámbito de este documento y son propiedad del controlador de audio del proveedor de SoC. El integrador del sistema debe trabajar directamente con el proveedor de silicio de SoC para implementar estas características propietarias en el subsistema de audio.

Modos de administración de energía

El subsistema de audio debe admitir los dos modos de administración de energía siguientes:

• Un modo activo en el que el audio se transmite activamente para el usuario.
• Un modo de suspensión de baja energía en el que la unidad de procesamiento de audio está desactivada, el códec fuera SoC se coloca en un modo de baja energía y los componentes del subsistema de audio combinado consumen menos de un milivatio.

En la tabla siguiente se describen estos dos modos de energía.

Mode	Descripción	Estado de energía del dispositivo (Dx)	Consumo medio de energía	Latencia de salida a activa	Mecanismo de transición
Activo (streaming)	Las unidades de procesamiento de audio transmiten audio de forma activa y el códec proporciona audio analógico o digital a un punto de conexión de audio, como auriculares, altavoces integrados o un dispositivo de salida HDMI remoto.	D0	<= 100 milivatios (procesamiento de audio + códec)	N/D	Transición a D0 iniciado por Portcls. Se produce cuando una aplicación o servicio del sistema inicia el streaming de audio.
En reposo	Las unidades de procesamiento de audio no transmiten audio y el códec no está operativo, excepto para la energía en espera suficiente para detectar la inserción o eliminación del conector.	D3	<= 1 milivatio (Recomendado).	<= 35 milisegundos o <= 300 milisegundos, según el escenario del sistema. (Requerido)	Transición a D3 iniciado por Portcls. Se produce cuando todas las aplicaciones finalizan el streaming de audio y expira el tiempo de espera de inactividad proporcionado por el controlador o el sistema.

En algunos diseños de SoC, las unidades de procesamiento de audio son bloques multifunción compartidos con la descodificación de vídeo y el procesamiento de gráficos. Con estos diseños, puede haber escenarios en los que las unidades de procesamiento de audio se enciendan cuando el audio no se transmite activamente.

Mecanismos de administración de energía de software

El mecanismo principal de administración de energía de software para el subsistema de audio es la detección de inactividad en tiempo de ejecución integrada en PortCls. La detección de inactividad en tiempo de ejecución permite a PortCls observar la actividad de streaming de audio de la aplicación para determinar cuándo debe cambiar el dispositivo de audio entre los modos de energía activo y de suspensión. PortCls también permite un mecanismo de extensión propietario entre el controlador de audio y el complemento del motor de alimentación proporcionado por el proveedor de SoC (PEP) para administrar el estado de rendimiento de las unidades de procesamiento de audio.

Detección de inactividad en tiempo de ejecución

Los componentes del subsistema de audio entran en el modo de suspensión de baja energía cuando el subsistema de audio está inactivo durante un intervalo de tiempo de espera especificado.

El controlador de audio proporcionado por el proveedor de SoC debe registrar los dos valores de tiempo de espera de inactividad predeterminados siguientes:

• PerformanceIdleTime: use este intervalo de tiempo de espera cuando la plataforma de hardware esté conectada a la alimentación de CA.
• ConservationIdleTime: use este intervalo de tiempo de espera cuando la plataforma funcione con batería.

La configuración de tiempo de espera de inactividad se almacena en las entradas del Registro que se encuentran en la clave del Registro PowerSettings del controlador de audio. Para obtener más información, consulte Implementación del temporizador de inactividad de clase de dispositivo de audio.

Las siguientes directivas .inf deben usarse para establecer un tiempo de espera PerformanceIdleTime de un segundo y un tiempo de espera de ConservationIdleTime de un 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

PortCls colabora con el administrador de energía del kernel de Windows para cambiar automáticamente entre los valores de tiempo de espera PerformanceIdleTime y ConservationIdleTime a medida que la plataforma alterna entre la energía de CA y la energía de la batería.

Cuando el sistema está en espera conectada (es decir, con la pantalla desactivada) y no se inicia la reproducción de audio, PortCls siempre usa un tiempo de espera de inactividad de un segundo, independientemente del valor de tiempo de espera que el controlador del adaptador especifique en su archivo .inf.

El controlador de audio proporcionado por el proveedor de SoC también debe registrar una configuración IdlePowerState para especificar el estado de energía al que se va a realizar la transición cuando expire el tiempo de espera de inactividad. En todas las plataformas en espera conectadas, los controladores de audio deben registrar D3 como el estado de energía al que entrar cuando se produce un tiempo de espera de inactividad. Para especificar el estado D3, la directiva AddReg del ejemplo anterior establece el valor IdlePowerState en 03.

Cuando expira el tiempo de espera de inactividad, PortCls llama al método IAdapterPowerManagement3::PowerChangeState3 del controlador de audio para indicar al controlador que debe preparar el dispositivo de audio para entrar en el modo de suspensión de baja energía (NewPowerState = PowerDeviceD3). El controlador de audio debe guardar contexto para la unidad de procesamiento de audio y colocar el códec en un modo de suspensión de baja energía que consuma menos de un milivatio, de media. En el modo de suspensión de baja energía, el códec debe seguir teniendo suficiente potencia para detectar la inserción o eliminación del conector de audio y generar una interrupción desencadenada por el nivel en el procesador principal en el SoC.

Cuando se requiere reproducción de audio debido al streaming de aplicaciones, generación de sonido del sistema o notificación sonora durante la espera conectada, PortCls llama al método PowerChangeState3 del controlador de audio para indicar al controlador que configure el dispositivo de audio para que funcione en el estado de energía activo (D0) (NewPowerState = PowerDeviceD0). El controlador de audio debe restaurar el contexto de la unidad de procesamiento de audio y volver a habilitar el códec.

PortCls llama al método IAdapterPowerManagement3::D 3ExitLatencyChanged del controlador de audio para notificar al controlador que se ha producido un cambio en la latencia máxima que se puede tolerar para las transiciones desde el estado de suspensión (D3) al estado activo (D0). PortCls llama al método D3ExitLatencyChanged del controlador de audio para establecer la latencia máxima en 35 milisegundos o 300 milisegundos. El controlador de audio debe respetar la tolerancia de latencia máxima y no entrar en un estado de baja energía que requiera una latencia de reanudación mayor que el valor especificado por PortCls en el método D3ExitLatencyChanged.

Administración de energía de códecs

El controlador de audio proporcionado por el proveedor de SoC también se encarga de configurar y administrar el códec de audio fuera de SoC. Normalmente, el controlador controla el códec de audio a través de una I²C u otra conexión de bus periférico simple (SPB) desde el SoC. El controlador también debe controlar las interrupciones del dispositivo de códec.

El controlador de audio debe pasar el códec a un modo de suspensión de baja energía cuando el subsistema de audio entra en estado D3 (suspensión).

El controlador de audio debe pasar el códec al modo activo cuando el subsistema de audio entra en estado D0 (activo).

Marco de energía de Windows (PoFx) y el complemento del motor de energía (PEP)

PortCls se registra en el marco de administración de energía de Windows para que se notifique al PEP proporcionado por el proveedor de SoC de las transiciones de dispositivo de audio entre los modos de energía activo (D0) y suspensión (D3). En muchos diseños de SoC, los raíles de reloj y alimentación de las unidades de procesamiento de audio se comparten con otros bloques funcionales en SoC. El PEP proporcionado por el proveedor de SoC es consciente de las topologías de reloj y alimentación específicas de SoC y toma la acción adecuada para detener los relojes o desactivar los raíles de alimentación asociados a la unidad de procesamiento de audio cuando está en modo de suspensión.

Además, PortCls admite un mecanismo privado denominado uso compartido de contexto que permite al controlador de audio comunicarse directamente con el PEP para realizar una administración de energía específica. Por ejemplo, un controlador de audio puede usar el uso compartido de contexto para informar al PEP del tipo de contenido de la secuencia de audio actual y la velocidad de bits. El PEP usa esta información para escalar la frecuencia del reloj de la unidad de procesamiento de audio hasta el mínimo necesario para procesar la secuencia de audio actual sin fallos.

La interfaz de uso compartido de contexto se define como un búfer de entrada y salida simple con un identificador GUID y es similar a otras interfaces extensibles de administración de energía de Windows. Para obtener más información sobre el uso compartido de contexto entre el controlador de minipuerto y el PEP, consulte Uso compartido de contexto de PEP privado de PortCls.

Configuración de energía de hardware admitida

En las plataformas en espera conectadas, Windows admite una única configuración de administración de energía de hardware para el subsistema de audio.

En la configuración esperada, las unidades de procesamiento de audio se encuentran en el SoC y el códec de audio externo está conectado al SoC a través de una interfaz de audio digital compatible con SoC, un bus periférico simple (SPB), como I²C, y uno o varios pines de GPIO. Se recomienda que el códec de audio y la lógica externa no consuman más de un milivatio en el modo de energía de suspensión.

En el diagrama de bloques siguiente se muestra la configuración de hardware esperada, la pila de controladores del dispositivo de audio y los componentes en modo de usuario.

El subsistema de audio puede tener componentes ubicados detrás del códec que no son visibles para el sistema operativo y sus controladores. Por ejemplo, estos componentes pueden incluir amplificadores para los altavoces y auriculares. Estos componentes son específicos de la plataforma y los puede seleccionar el integrador del sistema dentro de los requisitos descritos como parte del programa de certificación de Windows.

El integrador del sistema debe enumerar el dispositivo de audio SoC en la raíz de la jerarquía del espacio de nombres de APCI. Todos los recursos de memoria, E/S, GPIO e I²C (u otro SPB) necesarios para la unidad de procesamiento de audio y el códec externo deben aparecer en el objeto _CRS bajo el dispositivo, en el espacio de nombres. El integrador del sistema y el desarrollador de firmware ACPI deben comunicarse con el desarrollador del controlador de audio para conocer las convenciones para ordenar los recursos de hardware, como los pines de GPIO. Por ejemplo, un controlador que recibe dos recursos GPIO distingue entre ellos en función del orden en que aparecen en la lista de recursos. Para obtener más información, consulte Recursos de hardware basados en GPIO.

Aunque el controlador ACPI (Acpi.sys) puede observar las transiciones de activo (D0) y suspensión (D3) a medida que los IRP de alimentación del dispositivo fluyen a través de la pila de audio, el integrador del sistema no debe describir el códec de audio como parte de un recurso de alimentación o usar los métodos de control _PS0 y _PS3 ACPI para cambiar el estado de energía del códec. En modo de reposo, se espera que el códec funcione con una energía lo suficientemente baja como para que pueda dejarse encendido en todo momento para detectar la inserción y extracción de conectores.

El códec de audio y los amplificadores externos deben colocarse en un raíl de alimentación que esté siempre encendido, excepto cuando el sistema esté en estado de apagado ACPI (S5). Los pines de GPIO se pueden usar para habilitar o deshabilitar los amplificadores a petición. Los amplificadores se pueden controlar mediante pines de GPIO desde el códec o el SoC.

Un requisito clave es que el propio códec permanezca encendido en todo momento (incluso cuando está en modo de reposo de baja energía) para poder detectar la inserción y extracción del conector. El códec debe generar una interrupción que pueda reactivar el SoC de su estado de inactividad más profundo para gestionar la inserción y extracción del conector de auriculares.

Problemas de reactivación (detección de conectores de micrófono y auriculares)

El subsistema de audio debe controlar los cambios en el estado del dispositivo de salida de audio que puede producirse en cualquier momento. Los cambios de estado del dispositivo de audio más comunes son la inserción de un dispositivo de salida en el conector de auriculares integrado y la retirada de este dispositivo del conector. La inserción y extracción de conectores también debe detectarse para cualquier otro puerto de audio conectado, incluidos los puertos de micrófono y señal digital.

En todo momento, la pila de audio debe ser capaz de detectar la inserción y extracción de conectores. La línea de interrupción del códec de audio debe estar conectada a un pin de GPIO que siempre esté alimentado y siempre sea capaz de reactivar el SoC de su estado de suspensión más profundo. La detección de conectores permite a Windows mantener información actualizada sobre los dispositivos de entrada y salida de audio en tiempo real, incluidos todos los momentos en los que el sistema está en espera conectado. Por ejemplo, Windows recibe una notificación inmediata cuando el usuario introduce un conector en la toma de auriculares. En respuesta a esta notificación, los sonidos de alerta de notificación en espera conectados futuros se enrutan a los auriculares en lugar de a los altavoces integrados de la plataforma.

Como se ha descrito anteriormente, el firmware del sistema asigna un conjunto de recursos de hardware al dispositivo de audio. Estos recursos se describen en el objeto ACPI _CRS y el sistema operativo pasa una lista de estos recursos al controlador de audio. Esta lista de recursos incluye todas las interrupciones de GPIO que se usan para detectar cambios de estado en el dispositivo de salida de audio (por ejemplo, inserción de auriculares). Estas interrupciones deben marcarse en el firmware ACPI del sistema como orígenes de reactivación. Se espera que el controlador de audio agregue controladores de interrupción para cada una de estas interrupciones de reactivación. Los controladores de interrupción deben actualizar el estado del dispositivo de audio, el códec de audio y el controlador de audio, según corresponda, en función de la interrupción que se señalizó.

El orden de los recursos del objeto _CRS se basa en una convención específica del dispositivo definida por el desarrollador del controlador de audio. Por ejemplo, si el controlador recibe dos recursos de interrupción, el controlador distingue entre ellos en función del orden en que se producen en la lista de recursos. El desarrollador de firmware ACPI debe usar el mismo orden para describir estos recursos en el firmware ACPI.

Varios subsistemas de hardware, firmware y software deben colaborar para que la inserción y eliminación del conector de audio funcionen correctamente. El integrador del sistema y el desarrollador de controladores de audio deben cumplir las siguientes directrices de implementación:

Hardware y SoC

• El hardware del códec de audio debe detectar auriculares, micrófonos y otros eventos de inserción y eliminación de conectores en todo momento en el que el sistema está encendido, incluido cuando el sistema está en espera conectada.
• El hardware del códec de audio debe ser capaz de detectar la inserción y eliminación del conector mientras consume muy poca energía (menos de un milivatio de media).
• La interrupción del códec de audio debe estar conectada a un pin de GPIO en el SoC capaz de reactivar el SoC desde su estado de energía más profundo.

Firmware ACPI

• El dispositivo de audio debe describirse en el espacio de nombres ACPI.
• Las líneas de GPIO usadas para detectar la inserción de conectores deben describirse mediante el firmware ACPI como interrupciones exclusivas y de reactivación. Use la macro del descriptor GpioInt y establezca el argumento Shared en ExclusiveAndWake.
• Los recursos de hardware del dispositivo de audio deben aparecer en el orden esperado por el controlador de audio.

Software de controlador de audio

• El controlador de audio debe conectar un controlador de interrupción a las interrupciones de reactivación GPIO.
• Cuando el controlador de audio controla la interrupción, evalúa el estado de los dispositivos de entrada y salida de audio y realiza las acciones adecuadas.

Prueba y validación

Los integradores del sistema pueden usar Windows Performance Analyzer (WPA) para comprobar que el dispositivo de audio realiza correctamente la administración de energía inactiva en tiempo de ejecución y que realiza las transiciones según lo previsto entre los estados activo (D0) y suspensión (D3). WPA está disponible en el sitio web de Microsoft Connect. Póngase en contacto con su representante de Microsoft para obtener ayuda para obtener WPA y las extensiones de administración de energía de WPA. El integrador del sistema también debe obtener el paquete de herramientas de análisis de gestión de energía de WPA. Este paquete incluye extensiones a WPA que permiten el análisis de administración de energía del sistema.

WPA se basa en la instrumentación de Seguimiento de eventos para Windows (ETW) integrada en el kernel de Windows y en otros componentes de Windows, incluidos PortCls. Para usar el seguimiento de ETW, se habilita un conjunto de proveedores de seguimiento y sus eventos se registran en un archivo de registro mientras se ejecuta un escenario de prueba. Cuando finaliza el escenario, se detienen los proveedores de seguimiento. WPA habilita el posprocesamiento y el análisis visual del archivo de registro generado por el escenario en prueba.

En un sistema que tiene WPA instalado, se puede usar un conjunto de comandos para recopilar la instrumentación de administración de energía para validar la administración de energía del dispositivo de audio. La herramienta Xperf.exe se instala en la carpeta \%Archivos de programa%\Windows Kits\8.0\Windows Performance Analyzer.

Para iniciar el seguimiento de ETW de administración de energía, abra una ventana del símbolo del sistema como administrador, cambie al directorio que contiene WPA y ejecute los comandos siguientes:

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

Estos comandos indican a Windows que habilite el proveedor de eventos Microsoft-Windows-Kernel-Power ETW y capture el estado inicial de los eventos del proveedor Microsoft-Windows-Kernel-Power.

Una vez iniciado el seguimiento de ETW, el desarrollador debe ejecutar los escenarios del sistema para comprobar que el dispositivo de audio realiza correctamente la transición entre los modos de energía activo (D0) y suspensión (D3). El desarrollador debe validar el dispositivo de audio en los escenarios siguientes:

• Inicie una aplicación que realice la transición del dispositivo de audio del estado D3 al estado D0 .
• Un segundo después de cerrar todas las aplicaciones de audio, el dispositivo de audio pasa a D3 desde el estado D0.
• Cuando el sistema está en espera conectado, el dispositivo de audio permanece en estado D3.
• Cuando se genera una notificación sonora durante el modo en espera conectado, el dispositivo de audio pasa de D3 a D0, reproduce audio y, a continuación, vuelve a D3 después de un segundo.

Una vez completados estos escenarios de prueba, use el comando siguiente para detener la recopilación de seguimiento de ETW:

>xperf -stop powertracesession -d trace.etl

Use WPA para abrir el archivo Trace.etl resultante. Para iniciar WPA desde la línea de comandos, escriba el comando Wpa.exe.

En la herramienta WPA, seleccione el gráfico Dstate de dispositivo en la lista Explorador de gráficos y debería aparecer la siguiente vista.

En esta vista, un dispositivo se identifica por su nombre ACPI (por ejemplo, \_SB.AUDI) o la ruta de acceso de la instancia del dispositivo (por ejemplo, ACPI\MSFT0731\4%ffff367&2). Tanto el nombre de ACPI como la ruta de acceso de la instancia del dispositivo se muestran en la tabla de resumen del gráfico Dstate de dispositivo.

Para ver las transiciones de D-state realizadas por el dispositivo de audio, busque el nombre del dispositivo en la tabla de resumen, haga clic con el botón derecho en el nombre y elija Filtrar a selección. El gráfico resultante muestra solo las transiciones de D-state del dispositivo de audio, como se muestra en la captura de pantalla siguiente.

Este seguimiento de ejemplo muestra que el dispositivo de audio estaba en estado D3 (indicado por la coordenada 3 en el eje vertical) durante toda la duración del seguimiento, excepto durante un período de cinco segundos a unos 290 segundos desde el inicio del seguimiento.

Lista de comprobación de administración de energía

Los integradores del sistema y los proveedores de SoC deben usar la siguiente lista de comprobación para asegurarse de que el diseño de administración de energía de su subsistema de audio es compatible con Windows 8.1.

• El integrador del sistema debe trabajar estrechamente con el proveedor de SoC para integrar dispositivos de subsistema de audio.

• El controlador de audio desarrollado por el proveedor de SoC debe hacer lo siguiente:

  • Establecer tiempos de espera de inactividad en tiempo de ejecución cuando el sistema funcione con corriente alterna y con batería. El controlador de audio debe establecer el valor PerformanceIdleTime y el valor de ConservationIdleTime en un segundo.

  • Establecer el valor IdlePowerState en D3.

  • En el archivo .inf para el controlador de audio, establezca IdlePowerState, PerformanceIdleTime y ConservationIdleTime en los valores siguientes:

    [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
    

  • El controlador de audio debe guardar todo el contexto de la unidad de procesamiento de audio y colocar el códec en un modo de suspensión de baja energía cuando PortCls llama al método IAdapterPowerManagement3::PowerChangeState3 del controlador con un estado de energía del dispositivo de D3.

  • El controlador de audio debe restaurar todo el contexto de la unidad de procesamiento de audio y volver a habilitar el códec cuando PortCls llama al método PowerChangeState3 del controlador con un estado de energía del dispositivo D0.

  • El controlador de audio no debe usar estados de energía que infrinjan el requisito de latencia de salida D3 proporcionado por PortCls en el método IAdapterPowerManagement3:D3ExitLatencyChanged.

  • El controlador de audio debe controlar la configuración y la administración de energía del códec externo.

  • El controlador de audio debe controlar las interrupciones desencadenadas por el nivel desde el códec externo cuando el códec detecta la inserción o eliminación del conector.

• El proveedor de SoC debe proporcionar un complemento de motor de alimentación (PEP) que haga lo siguiente:

  • Colocar las unidades de procesamiento de audio en un estado de baja energía cuando el controlador de audio pasa al modo de suspensión (D3).
  • Activar cualquier raíl de reloj y alimentación necesarios para las unidades de procesamiento de audio cuando el controlador de audio pasa al modo de alimentación activo (D0).
  • Escalar correctamente el reloj y el voltaje suministrados a la unidad de procesamiento de audio según el nivel necesario de actividad de procesamiento, que depende del formato de audio, el tipo de contenido y la velocidad de bits.

• Para desarrollar la plataforma de hardware y firmware para el subsistema de audio, el integrador del sistema debe hacer lo siguiente:

  • Usar un códec que, en modo de suspensión, consuma menos de un milivatio, pero que pueda detectar eventos de inserción y eliminación de conectores.
  • Colocar el códec en un raíl de alimentación del sistema que esté encendido en todo momento, excepto cuando el sistema está en estado de apagado ACPI (S5).
  • Diseñar el firmware de ACPI para enumerar el subsistema de audio como un único dispositivo en la raíz de la jerarquía de espacios de nombres ACPI.
  • Determinar las convenciones de ordenación de recursos de memoria, interrupción, E/S, GPIO e I²C esperadas por el controlador de audio y asegurarse de que los recursos se muestran en el mismo orden en el objeto ACPI _CRS.

• Para probar y validar la administración de energía del subsistema de audio, el integrador del sistema debe hacer lo siguiente:

  • Comprobar que el controlador de audio pasa al estado de alimentación D3 cuando ninguna aplicación usa el subsistema de audio ni genera audio para el usuario.
  • Cuando esté en espera desde inactivo, comprobar que el controlador de audio permanece en el estado de alimentación D0 activo cuando una aplicación o el sistema genera audio, incluido durante la reproducción de audio cuando la pantalla está apagada.
  • Cuando está en espera desde la entrada explcit (pulsación del botón de encendido, comprobar que todas las secuencias de audio están cerradas desde el sistema operativo y el controlador de audio pasa al estado de alimentación D3 cuando una aplicación o el sistema generan audio (nuevo en el sistema operativo 24H2).
  • Comprobar que la reproducción de audio se realiza sin problemas mediante las pruebas proporcionadas en el Kit de laboratorio de hardware de Windows (HLK).
  • Asegurarse de que la detección de conectores funciona correctamente cuando el sistema está en espera conectado y que el audio se enruta correctamente a los auriculares o altavoces cuando el usuario inserta la clavija en la toma de auriculares o la retira de la toma.
  • Medir la energía que consumen la unidad de procesamiento de audio, el códec externo y cualquier circuito adicional de amplificación analógica. Asegurarse de que todo el subsistema de audio consume menos de un milivatio cuando está en estado de energía de suspensión (D3).