Gestion de l’alimentation du sous-système audio pour les plateformes de secours modernes

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 de secours connecté est généralement construite autour d’un circuit intégré Système sur puce (SoC) qui dispose d’unités de traitement audio intégrées à faible consommation d’énergie.

Les unités de traitement audio déchargent le traitement audio du processeur main (ou des processeurs) sur le SoC. Étant donné que ces unités peuvent traiter des données audio sans utiliser le processeur main, l’utilisateur peut continuer à écouter l’audio même après que le processeur main passe à un état de faible consommation pour économiser l’alimentation de la batterie.

Cette vidéo montre comment utiliser Windows Analyseur de performances (WPA) pour vérifier qu’un ordinateur passe à l’état de faible consommation pendant la lecture audio hors écran (également appelée audio à faible consommation d’énergie, ou LPA).

L’article suivant décrit la gestion de l’alimentation du sous-système audio pour les plateformes de secours connectées. Dans la discussion suivante, le terme composant on-SoC décrit un composant qui est intégré à la puce SoC. Un composant hors soC est externe à la puce SoC.

Vue d’ensemble du sous-système audio

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

• Convertit les flux numériques décodés en sons analogiques.
• Pilote des haut-parleurs intégrés.
• Pilote un casque analogique attaché à l’extérieur.

Comme avec un sous-système de caméra, le sous-système audio comprend à la fois des composants on-SoC et off-SoC. Toutefois, Windows s’attend à ce qu’un seul pilote audio gère à la fois les moteurs de traitement audio on-SoC et le codec off-SoC. Ce pilote audio unique est chargé de gérer à la fois les composants intégrés au SoC et les composants hors SoC qui peuvent être sélectionnés par l’intégrateur système. Par conséquent, l’intégrateur système doit travailler en étroite collaboration avec le fournisseur de silicium 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 miniport de classe de port (Portcls). Le pilote audio fonctionne conjointement avec le pilote système Portcls, Portcls.sys, qui est un composant de boîte de réception de Windows.

Par rapport à d’autres classes d’appareils, le sous-système audio est unique dans la façon dont il gère l’alimentation lorsque la plateforme est dans l’état d’alimentation de secours connecté (autrement dit, lorsque l’écran est éteint). Lorsque la plateforme est connectée en veille, le système peut générer des sons audio pour informer l’utilisateur des événements (par exemple, l’arrivée d’un nouvel e-mail) en temps réel. En outre, l’utilisateur peut désactiver l’affichage du système, puis continuer à écouter l’audio lu par une application. Ces fonctionnalités ne peuvent pas être obtenues par une stratégie de gestion de l’alimentation simple dans laquelle le sous-système audio doit être désactivé lorsque le système est en veille connectée. Au lieu de cela, la gestion de l’alimentation du sous-système audio doit être effectuée sur une base d’inactivité au moment de l’exécution (de sorte qu’il ne s’active que lorsque cela est nécessaire) à tout moment, sauf lorsque le système est à l’état d’arrêt ACPI (S5).

Le pilote audio effectue la gestion de l’alimentation inactive au moment de l’exécution en étroite coopération avec l’infrastructure audio 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) du périphérique audio et réinitialise le minuteur d’inactivité sur chaque accès. Si le minuteur d’inactivité expire, PortCls passe le périphérique audio (avec l’aide du pilote audio) à un état de veille à faible consommation (D3). PortCls retourne le périphérique audio à l’état actif (D0) en cas de nouvelle activité d’accès.

PortCls s’inscrit également auprès de l’infrastructure d’alimentation Windows (PoFx) afin que le plug-in du moteur d’alimentation (PEP) système puisse être averti des changements d’état d’alimentation du périphérique 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 de fonction 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 inclut la puissance consommée par les unités de traitement audio, le codec Hors-SoC et tout circuit audio supplémentaire (par exemple, les amplis pour les haut-parleurs et les casques).

Topologie matérielle du sous-système audio

Le sous-système audio est composé de plusieurs composants on-SoC et off-SoC, mais est présenté à Windows en tant qu’appareil unique dans l’espace de noms ACPI.

Les unités de traitement audio se trouvent sur le SoC. Les soC de différents fournisseurs ont des unités de traitement audio qui varient en ce qui a trait aux capacités, à la consommation d’énergie et aux performances. Les unités de traitement audio effectuent le déchargement audio: elles traitent les flux audio (par exemple, en mixant et en appliquant des effets audio) sans utiliser le processeur main. Pour la lecture audio qui n’est pas sensible à la latence, le déchargement de l’audio à partir du processeur main est préférable, car les unités de traitement audio utilisent moins d’énergie que le processeur main.

Pour plus d’informations sur l’audio déchargé, consultez Traitement audio déchargé par le matériel.

Le système comprend également un codec audio hors-SoC qui convertit le flux audio numérique en sortie analogique pour piloter des haut-parleurs intégrés ou des écouteurs externes. Le codec peut inclure des amplis analogiques intégrés pour les haut-parleurs et les casques. Vous pouvez également utiliser des amplis discrets à la place. Un codec classique a les connexions suivantes à l’unité de traitement audio on-SoC :

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

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

Du point de vue de Windows, l’unité de traitement audio et le codec audio constituent ensemble le périphérique 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 doit être exposé à Windows via un seul pilote audio, le fournisseur soC peut, en option, adopter un modèle d’extension de pilote dans lequel le pilote audio est décomposé en deux pilotes distincts ou plus. 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 main. Le pilote audio main gère ensuite indirectement le codec en communiquant avec le pilote de codec. Les détails de ce modèle d’extension de pilote ne sont pas dans le cadre de ce document et sont propriétaires du pilote audio du fournisseur soC. L’intégrateur système doit travailler directement avec le fournisseur de silicium SoC pour implémenter ces fonctionnalités propriétaires dans le sous-système audio.

Modes de gestion de l’alimentation

Le sous-système audio doit prendre en charge les deux modes de gestion de l’alimentation suivants :

• Mode actif dans lequel l’audio est activement diffusé pour l’utilisateur.
• Mode veille basse consommation dans lequel l’unité de traitement audio est désactivée, le codec SoC désactivé est placé en mode basse 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.

Mode	Description	État d’alimentation de l’appareil (Dx)	Consommation énergétique moyenne	Latence de sortie à actif	Mécanisme de transition
Actif (streaming)	Les unités de traitement audio diffusent activement de l’audio et le codec fournit de l’audio analogique ou numérique à un point de terminaison audio tel qu’un casque, des haut-parleurs intégrés ou un appareil de sortie HDMI distant.	D0	<= 100 milliwatts (traitement audio + codec)	N/A	Transition vers D0 initiée par Portcls. Se produit lorsqu’une application ou un service système lance la diffusion en continu audio.
Veille	Les unités de traitement audio ne sont pas de diffusion audio en continu et le codec n’est pas opérationnel, à l’exception d’une alimentation de secours suffisante pour détecter l’insertion ou la suppression de la prise.	D3	<= 1 milliwatt (Recommandé.)	<= 35 millisecondes ou <= 300 millisecondes, selon le scénario système. (Obligatoire.)	Transition vers D3 initiée par Portcls. Se produit lorsque toutes les applications terminent la diffusion audio et que le délai d’inactivité fourni par le pilote ou fourni par le système expire.

Dans certaines conceptions 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 lorsque l’audio n’est pas activement diffusé en continu.

Mécanismes de gestion de l’alimentation logicielle

Le principal mécanisme de gestion de l’alimentation logicielle pour le sous-système audio est la détection d’inactivité au moment de l’exécution intégrée à PortCls. La détection d’inactivité au moment de l’exécution permet aux PortCls d’observer l’activité de streaming audio de l’application pour déterminer quand basculer le périphérique audio entre les modes d’alimentation actif et veille. PortCls permet également d’utiliser un mécanisme d’extension propriétaire entre le pilote audio et le plug-in de moteur d’alimentation fourni par le fournisseur soC pour gérer l’état des performances des unités de traitement audio.

Détection des inactivités au moment de l’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 délai d’attente spécifié.

Le pilote audio fourni par le fournisseur soC doit inscrire les deux paramètres de délai d’inactivité par défaut suivants :

• PerformanceIdleTime : utilisez cet intervalle de délai d’attente lorsque la plateforme matérielle est branchée à l’alimentation secteur.
• ConservationIdleTime : utilisez cet intervalle de délai d’attente lorsque la plateforme s’exécute sur batterie.

Les paramètres de délai d’inactivité sont stockés dans les entrées de Registre situées sous la clé de Registre PowerSettings du pilote audio. Pour plus d’informations, consultez Implémentation du minuteur d’inactivité de la classe de périphérique audio.

Les directives .inf suivantes doivent être utilisées pour définir un délai d’attente PerformanceIdleTime d’une seconde et un délai d’attente 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’alimentation du noyau Windows pour basculer automatiquement entre les valeurs de délai d’expiration PerformanceIdleTime et ConservationIdleTime lorsque la plateforme effectue des transitions entre l’alimentation secteur et l’alimentation de la batterie.

Lorsque le système est en veille connectée (c’est-à-dire que l’écran est désactivé) 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 d’attente spécifié par le pilote de l’adaptateur dans son fichier .inf.

Le pilote audio fourni par le fournisseur de SoC doit également inscrire un paramètre IdlePowerState pour spécifier l’état d’alimentation vers lequel passer à l’expiration du délai d’inactivité. Sur toutes les plateformes de secours connectées, les pilotes audio doivent inscrire D3 comme état d’alimentation à entrer 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 sur 03.

À l’expiration du délai d’inactivité, PortCls appelle la méthode IAdapterPowerManagement3::P owerChangeState3 du pilote pour indiquer au pilote de préparer le périphérique audio à passer en mode veille faible (NewPowerState = PowerDeviceD3). Le pilote audio doit enregistrer 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 alimentation suffisante pour détecter l’insertion/la suppression de la prise audio et générer une interruption déclenchée au niveau du processeur main sur le SoC.

Lorsque la lecture audio est requise en raison de la diffusion en continu d’applications, de la génération de son 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 le périphérique audio pour fonctionner 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::D 3ExitLatencyChanged du pilote audio pour informer le pilote d’une modification de la latence maximale qui peut être tolérée pour les transitions de l’état veille (D3) à l’état actif (D0). PortCls appelle la méthode D3ExitLatencyChanged du pilote audio pour définir la latence maximale sur 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’alimentation des codecs

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

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

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

Windows Power Framework (PoFx) et le plug-in de moteur d’alimentation (PEP)

PortCls s’inscrit auprès del’infrastructure de gestion de l’alimentation Windows afin que le PEP fourni par le fournisseur de SoC soit informé des transitions de périphérique audio entre les modes d’alimentation actif (D0) et veille (D3). Dans de nombreuses conceptions de SoC, l’horloge et les rails d’alimentation des unités de traitement audio sont partagés avec d’autres blocs fonctionnels sur SoC. Le PEP fourni par le fournisseur de 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 pour désactiver 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 de l’alimentation affinée. 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 mettre à l’échelle la fréquence d’horloge de l’unité de traitement audio jusqu’au minimum requis pour traiter le flux audio actuel sans engloutance.

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

Configuration d’alimentation matérielle prise en charge

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

Dans la configuration attendue, les unités de traitement audio se trouvent sur le SoC, et le codec audio externe est connecté au SoC via une interface audio numérique compatible SoC, un bus périphérique simple (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 attendue, la pile de pilotes de périphérique audio et les composants en mode utilisateur.

Le sous-système audio peut avoir 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 écouteurs. Ces composants sont spécifiques à la plateforme et peuvent être sélectionnés par l’intégrateur système dans les conditions requises décrites dans le cadre du programme de certification Windows.

L’intégrateur système doit énumérer le périphérique audio 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 autres SPB) requises pour l’unité de traitement audio et le 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 de microprogrammes ACPI doivent communiquer avec le développeur de pilotes audio pour comprendre les conventions relatives à la commande des ressources matérielles, telles que les broches GPIO. Par exemple, un pilote qui reçoit deux ressources GPIO les distingue en fonction de l’ordre dans lequel elles apparaissent dans la liste des ressources. Pour plus d’informations, consultez Ressources matérielles basées sur GPIO.

Bien que le pilote ACPI (Acpi.sys) puisse observer les transitions actives (D0) et veille (D3) lorsque les IRP d’alimentation de l’appareil transitent dans la pile audio, l’intégrateur système ne doit pas décrire le codec audio dans le cadre d’une ressource d’alimentation ou 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 qu’il puisse être laissé sous tension à tout moment pour détecter l’insertion et la suppression d’une prise jack.

Le codec audio et tous les amplificateurs externes doivent être placés sur une rampe d’alimentation qui est toujours sous tension, sauf lorsque le système est à 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 à l’aide de broches GPIO à partir du codec ou du SoC.

Une exigence clé est 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 la suppression de jack puissent être détectées. Le codec doit générer une interruption qui peut sortir le SoC de son état d’inactivité le plus profond pour gérer l’insertion et la suppression de la prise casque.

Problèmes de veille (détection de prise casque et microphone)

Le sous-système audio doit gérer les modifications de l’état du périphérique de sortie audio qui peuvent se produire à tout moment. Les changements d’état de périphérique audio les plus courants sont l’insertion d’un périphérique de sortie dans la prise casque intégrée et la suppression de cet appareil de la prise jack. L’insertion et la suppression du jack doivent également être détectées pour tous les autres ports audio attaché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 la suppression de jack. 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 Jack permet à Windows de conserver des informations à jour sur les périphériques d’entrée et de sortie audio en temps réel, y compris toutes les fois où le système est en veille connectée. Par exemple, Windows est immédiatement averti lorsque l’utilisateur insère une prise dans la prise casque. En réponse à cette notification, les futurs sons d’alerte de notification de secours connectés sont acheminés vers le casque plutôt que vers les haut-parleurs intégrés de la plateforme.

Comme décrit précédemment, le microprogramme système affecte un ensemble de ressources matérielles au périphérique 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 inclut toutes les interruptions GPIO utilisées pour détecter les changements d’état dans le périphérique de sortie audio (par exemple, insertion de casque). Ces interruptions doivent être marquées dans le microprogramme ACPI système comme sources de veille. Le pilote audio est censé ajouter des gestionnaires d’interruption pour chacune de ces interruptions de veille. Les gestionnaires d’interruptions doivent mettre à jour l’état du périphérique audio, du codec audio et du pilote audio, le cas échéant, en fonction desquelles l’interruption a été 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 de pilotes audio. Par exemple, si le pilote reçoit deux ressources d’interruption, le pilote les distingue en fonction de l’ordre dans lequel elles se produisent dans la liste des ressources. Le développeur de microprogrammes 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 l’insertion et la détection de suppression de prise audio fonctionnent correctement. L’intégrateur système et le développeur de pilotes audio doivent respecter les instructions d’implémentation suivantes :

Matériel et SoC

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

Microprogramme ACPI

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

Logiciel de pilote audio

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

Test et validation

Les intégrateurs système peuvent utiliser windows Analyseur de performances (WPA) pour vérifier que l’appareil audio effectue correctement la gestion de l’alimentation inactif et les transitions au moment de l’exécution comme prévu entre les états actif (D0) et veille (D3). WPA est disponible sur le site web Microsoft Connect. Contactez votre représentant Microsoft pour obtenir de l’aide sur l’obtention des extensions WPA et wpa Power Management. L’intégrateur système doit également obtenir le package Wpa Power Management Analysis Tools. Ce package inclut des extensions à WPA qui permettent l’analyse de la gestion de l’alimentation système.

WPA s’appuie sur l’instrumentation de suivi d’événements pour Windows (ETW) intégrée au noyau Windows et à d’autres composants Windows, y compris PortCls. Pour utiliser le suivi ETW, un ensemble de fournisseurs de traces est activé et leurs événements sont enregistrés dans un fichier journal pendant l’exécution d’un scénario de test. Une fois le scénario terminé, les fournisseurs de trace sont arrêtés. WPA permet le post-traitement et l’analyse visuelle du fichier journal généré par le scénario en cours de test.

Sur un système sur lequel WPA est installé, un ensemble de commandes peut être utilisé pour collecter l’instrumentation de gestion de l’alimentation afin de valider la gestion de l’alimentation du périphérique audio. L’outil Xperf.exe est installé dans le dossier \%Program Files%\Windows Kits\8.0\Windows Analyseur de performances.

Pour démarrer le suivi ETW de gestion de l’alimentation, ouvrez une fenêtre d’invite de commandes en tant qu’administrateur, accédez au répertoire qui contient 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 Microsoft-Windows-Kernel-Power ETW et de capturer l’état initial des événements à partir du fournisseur Microsoft-Windows-Kernel-Power.

Une fois le suivi ETW démarré, le développeur doit exécuter des scénarios système pour vérifier que le périphérique audio passe correctement entre les modes d’alimentation actif (D0) et 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, le périphérique audio passe à D3 à partir de l’état D0.
• Lorsque le système est en mode de secours connecté, le périphérique audio reste à l’état D3.
• Lorsqu’une notification auditive est générée pendant la veille connectée, le périphérique audio passe de D3 à D0, lit l’audio, puis revient à D3 après une seconde.

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

>xperf -stop powertracesession -d trace.etl

Utilisez 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 Device Dstate dans la liste Graph Explorer et la vue suivante doit apparaître.

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

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

Cet exemple de trace montre que le périphérique audio était à 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 à partir du début de la trace.

Liste de contrôle de gestion de l’alimentation

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

• L’intégrateur de système doit travailler en étroite collaboration avec le fournisseur soC pour intégrer des appareils de sous-système audio.

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

  • Définissez des délais d’inactivité au moment de l’exécution lorsque le système s’exécute sur secteur et sur batterie. Le pilote audio doit définir la valeur PerformanceIdleTime et la valeur ConservationIdleTime sur une seconde.

  • Définissez la valeur IdlePowerState sur D3.

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

    [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 enregistrer 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::P owerChangeState3 du pilote avec un état d’alimentation de périphérique 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 du périphérique de D0.

  • Le pilote audio ne doit pas utiliser les états d’alimentation qui ne respectent pas 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 niveau du codec externe lorsque le codec détecte l’insertion ou la suppression d’une prise.

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

  • Place les unités de traitement audio dans un état de faible consommation lorsque le pilote audio passe en mode veille (D3).
  • Active les horloges et les rails d’alimentation nécessaires pour les unités de traitement audio lorsque le pilote audio passe au mode d’alimentation actif (D0).
  • Met correctement à l’échelle l’horloge et la tension fournies à l’unité de traitement audio en fonction du niveau requis d’activité de traitement, qui dépend du format audio, du type de contenu et de la vitesse de transmission.

• Pour développer la plateforme matérielle et de microprogramme pour le sous-système audio, l’intégrateur système doit effectuer les opérations suivantes :

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

• Pour tester et valider la gestion de l’alimentation du sous-système audio, l’intégrateur système doit effectuer les opérations suivantes :

  • Vérifiez que le pilote audio passe à l’état d’alimentation D3 quand aucune application n’utilise le sous-système audio ou ne génère de l’audio pour l’utilisateur.
  • Vérifiez que le pilote audio passe à 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.
  • Vérifiez que la lecture audio est effectuée sans problème et sans erreur à l’aide des tests fournis dans La suite de tests de certification Windows (HCK).
  • Assurez-vous que la détection de la prise 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 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. Vérifiez que l’ensemble du sous-système audio consomme moins d’un milliwatt lorsqu’il est en veille (D3).