Gestion de l'alimentation du sous-système audio pour les plates-formes modernes en veille

Chaque PC Windows dispose d'un sous-système audio qui permet à l'utilisateur d'écouter et d'enregistrer un son de haute qualité en temps réel. Une plateforme matérielle qui prend en charge le modèle d'alimentation en veille connectée est généralement construite autour d'un circuit intégré de type système sur puce (SoC) qui comporte des unités de traitement audio intégrées à faible consommation d'énergie.

Les unités de traitement audio déchargent le traitement audio du (ou des) processeur(s) principal(aux) du SoC. Comme ces unités peuvent traiter les données audio sans utiliser le processeur principal, l'utilisateur peut continuer à écouter le son même lorsque le processeur principal passe en mode basse consommation pour économiser l'énergie de la batterie.

Cette vidéo montre comment utiliser l'analyseur de performances Windows (WPA) pour vérifier qu'un ordinateur entre dans l'état de faible consommation d'énergie pendant la lecture audio hors écran (également connue sous le nom d'audio à faible consommation d'énergie, ou LPA).

L'article suivant traite de la gestion de l'alimentation du sous-système audio pour les plateformes connectées en veille. Dans la suite de la discussion, le terme composant sur SoC décrit un composant intégré dans la puce du SoC. Un composant hors SoC est externe à la puce du SoC.

Vue d'ensemble du sous-système audio

En plus des blocs fonctionnels du SoC qui effectuent le traitement audio déchargé, chaque plateforme de secours connectée comprend un composant hors SoC, appelé codec, qui effectue les opérations suivantes :

• Traduit les flux numériques décodés en sons analogiques.
• Pilote les haut-parleurs intégrés.
• Pilote les casques analogiques connectés en externe.

Comme pour le sous-système caméra, le sous-système audio présente des fonctionnalités à la fois on-SoC et off-SoC. Cependant, Windows s'attend à ce qu'un pilote audio unique gère à la fois les moteurs de traitement audio sur le SoC et le codec hors SoC. Ce pilote audio unique est responsable de la gestion des composants intégrés dans le SoC et des composants hors SoC qui peuvent être sélectionnés par l'intégrateur du système. Par conséquent, l'intégrateur de système doit travailler en étroite collaboration avec le fournisseur de silicium du SoC sur l'intégration du sous-système audio et la gestion de l'alimentation.

Le fournisseur de matériel audio doit implémenter le pilote audio en tant que pilote de mini-port de classe Port (Portcls). Le pilote audio fonctionne en conjonction avec le pilote système Portcls, Portcls.sys, qui est un composant de la boîte de réception de Windows.

Par rapport à d'autres classes d'appareils, le sous-système audio est unique en ce sens qu'il gère l'alimentation lorsque la plate-forme est en état de veille connectée (c'est-à-dire lorsque l'écran est éteint). Lorsque la plateforme est connectée en mode veille, le système peut générer des sons audio pour notifier à l'utilisateur des événements (par exemple, l'arrivée d'un nouvel e-mail) en temps réel. En outre, l'utilisateur peut éteindre l'écran du système et continuer à écouter le son diffusé par une application. Ces capacités ne peuvent pas être obtenues par une simple stratégie de gestion de l'énergie dans laquelle le sous-système audio doit être éteint lorsque le système est en veille connectée. Au contraire, la gestion de l'alimentation du sous-système audio doit être effectuée sur une base d'inactivité d'exécution (de sorte qu'il ne s'allume que lorsque cela est nécessaire) à tout moment, sauf lorsque le système est dans l'état d'arrêt ACPI (S5).

Le pilote audio effectue la gestion de l'énergie en mode inactif en étroite collaboration avec l'infrastructure audio de Windows et le pilote système PortCls. PortCls surveille tous les accès (tels que les accès aux E/S et aux propriétés) de l'appareil audio et réinitialise le délai d'inactivité à chaque accès. Si le délai d'inactivité expire, PortCls fait passer l'appareil audio (avec l'aide du pilote audio) à l'état de veille à faible consommation (D3). PortCls ramène l'appareil audio à l'état actif (D0) en cas de nouvelle activité d'accès.

PortCls s'enregistre également auprès du cadre d'alimentation Windows (PoFx) afin que le plug-in du moteur d'alimentation du système (PEP) puisse être informé des changements d'état d'alimentation des appareils audio. Ces notifications permettent au PEP de savoir quand il peut éteindre en toute sécurité les horloges et les rails d'alimentation qui peuvent être partagés entre les unités de traitement audio et d'autres blocs fonctionnels du SoC.

Nous recommandons que lorsque le sous-système audio n'est pas utilisé, il soit dans un état de veille dans lequel un total de moins d'un milliwatt est consommé par le sous-système audio. Ce total comprend l'énergie consommée par les unités de traitement audio, le codec off-SoC et tout circuit audio supplémentaire (par exemple, les amplificateurs pour les haut-parleurs et les casques).

Topologie matérielle du sous-système audio

Le sous-système audio est constitué de plusieurs composants on-SoC et off-SoC, mais il est présenté à Windows comme un appareil unique dans l'espace de noms ACPI.

Les unités de traitement audio sont situées sur le SoC. Les SoC de différents fournisseurs possèdent des unités de traitement audio dont les capacités, la consommation d'énergie et les performances varient. Les unités de traitement audio effectuent un déchargement audio, c'est-à-dire qu'elles traitent les flux audio (par exemple, en les mixant et en appliquant des effets audio) sans utiliser le processeur principal. Pour la lecture audio qui n'est pas sensible à la latence, il est préférable de décharger l'audio du processeur principal car les unités de traitement audio consomment moins d'énergie que le processeur principal.

Pour plus d'informations sur le traitement audio déchargé, reportez-vous à la section Traitement audio déchargé au niveau matériel.

Le système comprend également un codec audio hors-SoC qui convertit le flux audio numérique en sortie analogique pour faire fonctionner les haut-parleurs intégrés ou les écouteurs externes. Le codec peut inclure des amplificateurs analogiques intégrés pour les haut-parleurs et les casques. Il est également possible d'utiliser des amplificateurs discrets. Un codec typique possède les connexions suivantes à l'unité de traitement audio on-SoC :

• Une interface audio numérique (I2S ou bus série similaire).
• Une interface de contrôle (typiquement I2C ou bus série similaire).
• Une ou plusieurs broches GPIO pour contrôler les circuits de gestion de l'alimentation et pour interrompre le SoC lorsque l'état du codec change.

Ces connexions sont illustrées dans le diagramme de blocs suivant.

Du point de vue de Windows, l'unité de traitement audio et le codec audio constituent ensemble l'appareil audio. Le périphérique audio doit être énuméré dans l'espace de noms ACPI en tant qu'objet d'appareil unique.

Bien que le sous-système audio doive être exposé à Windows par l'intermédiaire d'un seul pilote audio, le fournisseur du SoC peut, en option, adopter un modèle d'extension de pilote dans lequel le pilote audio est décomposé en deux ou plusieurs pilotes distincts. Par exemple, le logiciel de contrôle qui gère directement le codec audio peut être placé dans un pilote de codec distinct du pilote audio principal. Le pilote audio principal gère alors indirectement le codec en communiquant avec le pilote de codec. Les détails de ce modèle d'extension de pilote sortent du cadre de ce document et sont la propriété du pilote audio du fournisseur du SoC. L'intégrateur de système doit travailler directement avec le fournisseur de silicium du SoC pour mettre en œuvre ces fonctionnalités propriétaires dans le sous-système audio.

Modes de gestion de l'énergie

Le sous-système audio doit prendre en charge les deux modes de gestion de l'énergie suivants :

• Un mode actif dans lequel l'audio est activement diffusé pour l'utilisateur.
• Un mode de veille à faible consommation dans lequel l'unité de traitement audio est éteinte, le codec hors-SoC est placé dans un mode à faible consommation, et les composants combinés du sous-système audio consomment moins d'un milliwatt.

Le tableau suivant décrit ces deux modes d'alimentation.

Dans certaines conceptions de SoC, les unités de traitement audio sont des blocs multifonctions partagés avec le décodage vidéo et le traitement graphique. Avec ces conceptions, il peut y avoir des scénarios dans lesquels les unités de traitement audio sont sous tension alors que l'audio n'est pas en cours de diffusion.

Mécanismes logiciels de gestion de l'énergie

Le principal mécanisme logiciel de gestion de l'énergie pour le sous-système audio est la détection d'inactivité en cours d'exécution, qui est intégrée dans PortCls. Cette détection permet à PortCls d'observer l'activité du flux audio de l'application afin de déterminer quand basculer l'appareil audio entre le mode actif et le mode veille. PortCls permet également un mécanisme d'extension propriétaire entre le pilote audio et le plug-in de moteur d'alimentation (PEP) fourni par le fournisseur du SoC pour gérer l'état de performance des unités de traitement audio.

Détection de l'inactivité en cours d'exécution

Les composants du sous-système audio passent en mode veille à faible consommation après que le sous-système audio est inactif pendant un intervalle de temps spécifié.

Le pilote audio fourni par le fournisseur du SoC doit enregistrer les deux paramètres de délai d'inactivité par défaut suivants :

• PerformanceIdleTime - Utilisez cet intervalle de temps lorsque la plate-forme matérielle est branchée sur le secteur.
• ConservationIdleTime - Utilisez cet intervalle de temps lorsque la plateforme fonctionne sur batterie.

Les paramètres de délai d'inactivité sont stockés dans des entrées de registre situées sous la clé de registre PowerSettings du pilote audio. Pour plus d'informations, consultez la section Mise en œuvre de la minuterie d'inactivité de la classe d'appareil audio.

Les directives .inf suivantes doivent être utilisées pour définir un délai PerformanceIdleTime d'une seconde et un délai ConservationIdleTime d'une seconde :

[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 collabore avec le gestionnaire d'énergie du noyau Windows pour basculer automatiquement entre les valeurs PerformanceIdleTime et ConservationIdleTime lorsque la plate-forme passe de l'alimentation CA à l'alimentation par batterie.

Lorsque le système est en veille connectée (c'est-à-dire avec l'écran éteint) et que la lecture audio n'est pas lancée, PortCls utilise toujours un délai d'inactivité d'une seconde, quel que soit le paramètre de délai spécifié par le pilote de l'adaptateur dans son fichier .inf.

Le pilote audio fourni par le vendeur du SoC doit également enregistrer un paramètre IdlePowerState pour spécifier l'état d'alimentation à adopter à l'expiration du délai d'inactivité. Sur toutes les plateformes de veille connectées, les pilotes audio doivent enregistrer D3 comme état d'alimentation à atteindre lorsqu'un délai d'inactivité se produit. Pour spécifier l'état D3, la directive AddReg de l'exemple précédent définit la valeur IdlePowerState à 03.

À l'expiration du délai d'inactivité, PortCls appelle la méthode IAdapterPowerManagement3::PowerChangeState3 du pilote audio pour indiquer au pilote de préparer l'appareil audio à passer en mode veille à faible consommation (NewPowerState = PowerDeviceD3). Le pilote audio doit sauvegarder le contexte pour l'unité de traitement audio et placer le codec dans un mode de veille à faible consommation qui consomme moins d'un milliwatt, en moyenne. En mode veille à faible consommation, le codec doit continuer à disposer d'une puissance suffisante pour détecter l'insertion/le retrait de la prise audio et générer une interruption déclenchée par le niveau vers le processeur principal du SoC.

Lorsque la lecture audio est nécessaire en raison de la diffusion d'une application, de la génération d'un son par le système ou d'une notification auditive pendant la veille connectée, PortCls appelle la méthode PowerChangeState3 du pilote audio pour indiquer au pilote de configurer l'appareil audio afin qu'il fonctionne dans l'état d'alimentation actif (D0) (NewPowerState = PowerDeviceD0). Le pilote audio doit restaurer le contexte de l'unité de traitement audio et réactiver le codec.

PortCls appelle la méthode IAdapterPowerManagement3::D3ExitLatencyChanged du pilote audio pour notifier au pilote une modification de la latence maximale pouvant être tolérée pour les transitions de l'état de veille (D3) à l'état actif (D0). PortCls appelle la méthode D3ExitLatencyChanged du pilote audio pour fixer la latence maximale à 35 millisecondes ou 300 millisecondes. Le pilote audio doit respecter la tolérance de latence maximale et ne pas entrer dans un état de faible consommation qui nécessite une latence de reprise supérieure à la valeur spécifiée par PortCls dans la méthode D3ExitLatencyChanged.

Gestion de l'énergie du codec

Le pilote audio fourni par le fournisseur du SoC est également responsable de la configuration et de la gestion de l'alimentation du codec audio hors SoC. Le pilote contrôle généralement le codec audio par le biais d'une connexion I²C ou d'un autre bus périphérique simple (SPB) du SoC. Le pilote doit également gérer les interruptions provenant de l'appareil du codec.

Le pilote audio doit faire passer le codec en mode veille à faible consommation lorsque le sous-système audio entre dans l'état D3 (veille).

Le pilote audio doit faire passer le codec en mode d'alimentation active lorsque le sous-système audio entre dans l'état D0 (actif).

Cadre d'alimentation Windows (PoFx) et le plug-in de moteur d'alimentation (PEP)

PortCls s'enregistre auprès du cadre de gestion de l'alimentation Windows afin que le PEP fourni par le fournisseur du SoC soit informé des transitions de l'appareil audio entre les modes d'alimentation actif (D0) et sommeil (D3). Dans de nombreuses conceptions de SoC, les rails d'horloge et d'alimentation des unités de traitement audio sont partagés avec d'autres blocs fonctionnels on-SoC. Le PEP fourni par le fournisseur du SoC connaît les topologies d'horloge et d'alimentation spécifiques au SoC et prend les mesures appropriées pour arrêter les horloges ou éteindre les rails d'alimentation associés à l'unité de traitement audio lorsqu'elle est en mode veille.

En outre, PortCls prend en charge un mécanisme privé appelé partage de contexte qui permet au pilote audio de communiquer directement avec le PEP pour effectuer une gestion fine de l'énergie. Par exemple, un pilote audio peut utiliser le partage de contexte pour informer le PEP du type de contenu et du débit binaire du flux audio actuel. Le PEP utilise ces informations pour réduire la fréquence d'horloge de l'unité de traitement audio au minimum requis pour traiter le flux audio actuel sans problème.

L'interface de partage de contexte est définie comme une simple mémoire tampon d'entrée/sortie avec un identifiant GUID, et est similaire à d'autres interfaces extensibles de gestion de l'alimentation de Windows. Pour plus d'informations sur le partage de contexte entre le pilote du miniport et le PEP, consultez la section Partage de contexte PEP privé PortCls.

Configuration matérielle de l'alimentation prise en charge

Dans les plateformes de veille connectées, Windows prend en charge une seule configuration matérielle de gestion de l'alimentation pour le sous-système audio.

Dans la configuration prévue, les unités de traitement audio sont situées sur le SoC, et le codec audio externe est connecté au SoC via une interface audio numérique compatible avec le SoC, un simple bus périphérique (SPB) tel que I²C, et une ou plusieurs broches GPIO. Nous recommandons que le codec audio et la logique externe ne consomment pas plus d'un milliwatt en mode veille.

Le diagramme de blocs suivant montre la configuration matérielle prévue, la pile du pilote de l'appareil audio et les composants du mode utilisateur.

Le sous-système audio peut comporter des composants situés derrière le codec qui ne sont pas visibles par le système d'exploitation et ses pilotes. Par exemple, ces composants peuvent inclure des amplificateurs pour les haut-parleurs et les casques. Ces composants sont spécifiques à la plate-forme et peuvent être sélectionnés par l'intégrateur du système dans le cadre des exigences définies dans le programme de certification Windows.

L'intégrateur système doit énumérer l'appareil audio du SoC à la racine de la hiérarchie de l'espace de noms APCI. Toutes les ressources mémoire, E/S, GPIO et I²C (ou autre SPB) nécessaires à l'unité de traitement audio et au codec externe doivent être répertoriées dans l'objet _CRS sous l'appareil dans l'espace de noms. L'intégrateur système et le développeur du microprogramme ACPI doivent communiquer avec le développeur du pilote audio pour comprendre les conventions d'ordonnancement des ressources matérielles, telles que les broches GPIO. Par exemple, un pilote qui reçoit deux ressources GPIO les distingue en fonction de leur ordre d'apparition dans la liste des ressources. Pour plus d'informations, voir Ressources matérielles basées sur les GPIO.

Bien que le pilote ACPI (Acpi.sys) puisse observer les transitions actif (D0) et veille (D3) lorsque les IRP d'alimentation de l'appareil passent par la pile audio, l'intégrateur système ne doit pas décrire le codec audio comme faisant partie d'une ressource d'alimentation ni utiliser les méthodes de contrôle ACPI _PS0 et _PS3 pour modifier l'état d'alimentation du codec. En mode veille, le codec est censé fonctionner à une puissance suffisamment faible pour pouvoir être laissé sous tension à tout moment afin de détecter l'insertion et le retrait d'un jack.

Le codec audio et tout amplificateur externe doivent être placés sur un rail d'alimentation qui est toujours sous tension, sauf lorsque le système est dans l'état d'arrêt ACPI (S5). Les broches GPIO peuvent être utilisées pour activer ou désactiver les amplificateurs à la demande. Les amplificateurs peuvent être contrôlés en utilisant les broches GPIO du codec ou du SoC.

Il est essentiel que le codec lui-même reste alimenté à tout moment, même lorsqu'il est en mode veille à faible consommation, afin que l'insertion et le retrait du jack puissent être détectés. Le codec doit générer une interruption capable de réveiller le SoC de son état d'inactivité le plus profond pour gérer l'insertion et le retrait de la prise casque.

Problèmes de réveil (détection de la prise du casque et du microphone)

Le sous-système audio doit gérer les changements d'état de l'appareil de sortie audio qui peuvent survenir à tout moment. Les changements d'état les plus courants des appareils audio sont l'insertion d'un appareil de sortie dans la prise casque intégrée et le retrait de cet appareil de la prise. L'insertion et le retrait de la prise doivent également être détectés pour tous les autres ports audio connectés, y compris les ports de microphone et de signal numérique.

À tout moment, la pile audio doit être en mesure de détecter l'insertion et le retrait de la prise. La ligne d'interruption du codec audio doit être connectée à une broche GPIO toujours alimentée et toujours capable de réveiller le SoC de son état d'inactivité le plus profond. La détection des prises permet à Windows de conserver des informations à jour sur les appareils d'entrée et de sortie audio en temps réel, y compris à tout moment lorsque le système est en veille connectée. Par exemple, Windows est immédiatement averti lorsque l'utilisateur insère un plug-in dans la prise du casque. En réponse à cette notification, tout futur son d'alerte de notification de veille connectée est acheminé vers les écouteurs plutôt que vers les haut-parleurs intégrés de la plateforme.

Comme décrit précédemment, le microprogramme du système attribue un ensemble de ressources matérielles à l'appareil audio. Ces ressources sont décrites dans l'objet ACPI _CRS, et le système d'exploitation transmet une liste de ces ressources au pilote audio. Cette liste de ressources comprend toutes les interruptions GPIO utilisées pour détecter les changements d'état de l'appareil de sortie audio (par exemple, l'insertion d'un casque). Ces interruptions doivent être marquées dans le microprogramme ACPI du système comme sources de réveil. Le pilote audio doit ajouter des gestionnaires d'interruption pour chacune de ces interruptions de réveil. Les gestionnaires d'interruption doivent mettre à jour l'état de l'appareil audio, du codec audio et du pilote audio, selon le cas, en fonction de l'interruption signalée.

L'ordre des ressources dans l'objet _CRS est basé sur une convention spécifique à l'appareil, définie par le développeur du pilote audio. Par exemple, si le pilote reçoit deux ressources d'interruption, il les distingue en fonction de leur ordre d'apparition dans la liste des ressources. Le développeur du microprogramme ACPI doit utiliser le même ordre pour décrire ces ressources dans le microprogramme ACPI.

Plusieurs sous-systèmes matériels, microprogrammes et logiciels doivent collaborer pour que la détection de l'insertion et du retrait de la prise audio fonctionne correctement. L'intégrateur système et le développeur du pilote audio doivent respecter les directives de mise en œuvre suivantes :

Matériel et SoC

• Le matériel du codec audio doit détecter les événements d'insertion et de retrait du casque, du microphone et d'autres prises à tout moment lorsque le système est sous tension, y compris lorsque le système est en veille connectée.
• Le codec audio doit être capable de détecter l'insertion et le retrait de la prise tout en consommant très peu d'énergie (moins d'un milliwatt en moyenne).
• L'interruption du codec audio doit être connectée à une broche GPIO du SoC capable de réveiller le SoC à partir de son état d'alimentation le plus bas.

Microprogramme ACPI

• L'appareil audio doit être décrit dans l'espace de noms ACPI.
• Les lignes GPIO utilisées pour détecter l'insertion du jack doivent être décrites par le microprogramme ACPI comme des interruptions exclusives et de réveil. Utilisez la macro descripteur GpioInt et définissez l'argument Shared sur ExclusiveAndWake.
• Les ressources matérielles de l'appareil audio doivent être répertoriées dans l'ordre attendu par le pilote audio.

Logiciel du pilote audio

• Le pilote audio doit connecter un gestionnaire d'interruption aux interruptions de réveil GPIO.
• Lorsque le pilote audio gère l'interruption, il évalue l'état des appareils d'entrée/sortie audio et effectue les actions appropriées.

Test et validation

Les intégrateurs de systèmes peuvent utiliser l'analyseur de performances Windows (WPA) pour vérifier que l'appareil audio gère correctement l'alimentation au repos pendant l'exécution et passe comme prévu de l'état actif (D0) à l'état de veille (D3). Le WPA est disponible sur le site web Microsoft Connect. Veuillez contacter votre représentant Microsoft pour obtenir de l'aide dans l'obtention du WPA et des extensions de gestion de l'alimentation du WPA. L'intégrateur de système doit également se procurer le package WPA Power Management Analysis Tools (outils d'analyse de la gestion de l'alimentation). Ce package comprend des extensions du WPA qui permettent d'analyser la gestion de l'énergie du système.

Le WPA s'appuie sur l'instrumentation Event Tracing for Windows (ETW) qui est intégrée au noyau Windows et à d'autres composants Windows, y compris PortCls. Pour utiliser le traçage ETW, un ensemble de fournisseurs de traçage sont activés et leurs événements sont enregistrés dans un fichier journal pendant l'exécution d'un scénario de test. Lorsque le scénario se termine, les fournisseurs de trace sont arrêtés. La WPA permet le post-traitement et l'analyse visuelle du fichier journal généré par le scénario testé.

Sur un système sur lequel WPA est installé, un ensemble de commandes peut être utilisé pour collecter des instruments de gestion de l'alimentation afin de valider la gestion de l'alimentation de l'appareil audio. L'outil Xperf.exe est installé dans le dossier \NProgram Files%\NWindows Kits\N8.0\NWindows Performance Analyzer.

Pour lancer le traçage de la gestion de l'alimentation ETW, ouvrez une fenêtre d'invite de commande en tant qu'administrateur, accédez au répertoire qui contient la WPA et exécutez les commandes suivantes :

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

Ces commandes indiquent à Windows d'activer le fournisseur d'événements ETW Microsoft-Windows-Kernel-Power et de capturer l'état initial des événements du fournisseur Microsoft-Windows-Kernel-Power.

Une fois que le traçage ETW a démarré, le développeur doit exercer des scénarios système pour vérifier que l'appareil audio passe correctement du mode actif (D0) au mode veille (D3). Le développeur doit valider l'appareil audio dans les scénarios suivants :

• Lancez une application qui fait passer l'appareil audio de l'état D3 à l'état D0.
• Une seconde après la fermeture de toutes les applications audio, l'appareil audio passe de l'état D0 à l'état D3.
• Lorsque le système est en veille connectée, l'appareil audio reste dans l'état D3.
• Lorsqu'une notification auditive est générée pendant la veille connectée, l'appareil audio passe de D3 à D0, joue de l'audio, puis revient à D3 au bout d'une seconde.

Une fois ces scénarios de test terminés, utilisez la commande suivante pour arrêter la collecte de traces ETW :

>xperf -stop powertracesession -d trace.etl

Utilisez la WPA pour ouvrir le fichier Trace.etl résultant. Pour lancer WPA à partir de la ligne de commande, entrez la commande Wpa.exe.

Dans l'outil WPA, sélectionnez le graphique de l'état D de l'appareil dans la liste de l'Explorateur de graphiques, et la vue suivante devrait apparaître.

Dans cette vue, un appareil est identifié soit par son nom ACPI (par exemple, \_SB.AUDI), soit par le chemin d'accès à l'instance de l'appareil (par exemple, ACPI\MSFT0731\4%ff367&2). Le nom ACPI et le chemin d'accès à l'instance de l'appareil sont tous deux répertoriés dans le tableau récapitulatif du graphique d'état D de l'appareil.

Pour afficher les transitions d'état D effectuées par l'appareil audio, recherchez le nom de l'appareil dans le tableau récapitulatif, cliquez avec le bouton droit de la souris sur le nom et choisissez Filtrer sur la sélection. Le graphique résultant affiche les transitions d'état D de l'appareil audio uniquement, comme le montre la capture d'écran suivante.

Cet exemple de trace montre que l'appareil audio était dans l'état D3 (indiqué par la coordonnée 3 sur l'axe vertical) pendant toute la durée de la trace, à l'exception d'une période de cinq secondes à environ 290 secondes du début de la trace.

Liste de contrôle de la gestion de l'énergie

Les intégrateurs de systèmes et les fournisseurs de circuits intégrés doivent utiliser la liste de contrôle suivante pour s'assurer que la conception de la gestion de l'alimentation de leur sous-système audio est compatible avec Windows 8.1.

• L'intégrateur système doit travailler en étroite collaboration avec le fournisseur de SoC pour intégrer les appareils du sous-système audio.

• Le pilote audio développé par le fournisseur du SoC doit effectuer les opérations suivantes :

  • Définir les délais d'inactivité en cours d'exécution lorsque le système fonctionne sur secteur et sur batterie. Le pilote audio doit fixer les valeurs PerformanceIdleTime et ConservationIdleTime à une seconde.

  • Définissez la valeur IdlePowerState sur D3.

  • Dans le fichier .inf du pilote audio, définissez les valeurs IdlePowerState, PerformanceIdleTime et ConservationIdleTime comme suit :

    [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
    

  • Le pilote audio doit sauvegarder tout le contexte de l'unité de traitement audio et placer le codec en mode veille à faible consommation lorsque PortCls appelle la méthode IAdapterPowerManagement3::PowerChangeState3 du pilote avec un état d'alimentation de l'appareil de D3.

  • Le pilote audio doit restaurer tout le contexte de l'unité de traitement audio et réactiver le codec lorsque PortCls appelle la méthode PowerChangeState3 du pilote avec un état d'alimentation de l'appareil de D0.

  • Le pilote audio ne doit pas utiliser des états d'alimentation qui violent l'exigence de latence de sortie D3 fournie par PortCls dans la méthode IAdapterPowerManagement3:D3ExitLatencyChanged.

  • Le pilote audio doit gérer la configuration et la gestion de l'alimentation du codec externe.

  • Le pilote audio doit gérer les interruptions déclenchées par le codec externe lorsque le codec détecte l'insertion ou le retrait d'un jack.

• Le fournisseur du SoC doit fournir un plug-in de moteur d'alimentation (PEP) qui effectue les opérations suivantes :

  • Met les unités de traitement audio dans un état de faible consommation lorsque le pilote audio passe en mode veille (D3).
  • Il active tous les rails d'horloge et d'alimentation nécessaires aux unités de traitement audio lorsque le pilote audio passe en mode d'alimentation active (D0).
  • Il échelonne correctement l'horloge et la tension fournies à l'unité de traitement audio en fonction du niveau d'activité de traitement requis, qui dépend du format audio, du type de contenu et du débit binaire.

• Pour développer la plate-forme matérielle et le microprogramme du sous-système audio, l'intégrateur de système doit procéder comme suit :

  • Utiliser un codec qui, en mode veille, consomme moins d'un milliwatt mais peut encore détecter les événements d'insertion et de retrait du jack.
  • Placez le codec sur un rail d'alimentation du système qui est toujours allumé, sauf lorsque le système est dans l'état d'arrêt ACPI (S5).
  • Concevez le microprogramme ACPI de manière à énumérer le sous-système audio comme un appareil unique à la racine de la hiérarchie de l'espace de noms ACPI.
  • Déterminez les conventions d'ordonnancement des ressources mémoire, interruption, E/S, GPIO et I²C attendues par le pilote audio et assurez-vous que les ressources sont énumérées dans le même ordre dans l'objet ACPI _CRS.

• Pour tester et valider la gestion de l'alimentation du sous-système audio, l'intégrateur système doit procéder comme suit :

  • Vérifiez que le pilote audio passe à l'état d'alimentation D3 lorsqu'aucune application n'utilise le sous-système audio ou ne génère de l'audio pour l'utilisateur.
  • Lorsqu'il est en veille, vérifiez que le pilote audio reste dans l'état d'alimentation actif D0 lorsqu'une application ou le système génère de l'audio, y compris pendant la lecture audio lorsque l'écran est éteint.
  • Lorsque vous êtes en veille et que vous appuyez sur le bouton d'alimentation, vérifiez que tous les flux audio sont fermés par le système d'exploitation et que le pilote audio passe à l'état d'alimentation D3 lorsqu'une application ou le système génère de l'audio (nouveau dans OS 24H2).
  • Vérifiez que la lecture audio s'effectue sans problème ni erreur à l'aide des tests fournis dans le Windows Hardware Lab Kit (HLK).
  • Assurez-vous que la détection des prises fonctionne correctement lorsque le système est en veille connectée, et que l'audio est correctement acheminé vers le casque ou les haut-parleurs lorsque l'utilisateur insère la fiche dans la prise du casque ou retire la fiche de la prise.
  • Mesurez la puissance consommée par l'unité de traitement audio, le codec externe et tout circuit d'amplification analogique supplémentaire. Assurez-vous que l'ensemble du sous-système audio consomme moins d'un milliwatt lorsqu'il est en état de veille (D3).