Energieverwaltung für Audiosubsysteme für moderne Standbyplattformen

Jeder Windows-PC verfügt über ein Audiosubsystem, mit dem Benutzer hochwertigen Sound in Echtzeit hören und aufzeichnen können. Eine Hardwareplattform, die den verbundenen Standbymodus unterstützt, ist in der Regel um einen integrierten SoC-Schaltkreis (System on a Chip) herum aufgebaut, der integrierte Audioverarbeitungseinheiten mit geringem Energiebedarf bietet.

Die Audioverarbeitungseinheiten lagern die Audioverarbeitung vom Hauptprozessor (bzw. von den Hauptprozessoren) an das SoC aus. Da diese Einheiten Audiodaten ohne Verwendung des Hauptprozessors verarbeiten können, können Benutzer auch dann weiterhin die Audiowiedergabe nutzen, nachdem der Hauptprozessor in einen Zustand mit geringem Energiebedarf wechselt, um Akkuleistung zu sparen.

In diesem Video wird gezeigt, wie Sie Windows Performance Analyzer (WPA) verwenden, um sicherzustellen, dass ein Computer während der Audiowiedergabe bei deaktiviertem Bildschirm (auch als Low-Power Audio oder LPA bezeichnet) in einen Zustand mit geringem Energiebedarf wechselt.

Im folgenden Artikel wird die Energieverwaltung für das Audiosubsystem für verbundene Standbyplattformen erläutert. In der folgenden Diskussion beschreibt der Begriff On-SoC-Komponente eine Komponente, die in den SoC-Chip integriert ist. Eine Off-SoC-Komponente befindet sich außerhalb des SoC-Chips.

Übersicht über das Audiosubsystem

Zusätzlich zu den SoC-Funktionsblöcken, die die ausgelagerte Audioverarbeitung übernehmen, umfasst jede verbundene Standbyplattform eine Off-SoC-Komponente, die als Codec bezeichnet wird und Folgendes ausführt:

• Übersetzt dekodierte digitale Datenströme in analoge Sounds.
• Versorgt integrierte Lautsprecher.
• Versorgt extern angeschlossene analoge Kopfhörer.

Wie bei einem Kamerasubsystem enthält auch das Audiosubsystem sowohl On-SoC- als auch Off-SoC-Komponenten. Windows erwartet jedoch, dass ein einziger Audiotreiber sowohl die On-SoC-Audioverarbeitungsmodule als auch den Off-SoC-Codec verwaltet. Dieser eine Audiotreiber verwaltet sowohl die in das SoC integrierten Komponenten als auch die Off-SoC-Komponenten, die vom Systemintegrator ausgewählt werden können. Daher sollte der Systemintegrator bei der Integration und Energieverwaltung des Audiosubsystems eng mit dem Anbieter des SoC-Chips zusammenarbeiten.

Der Anbieter der Audiohardware muss den Audiotreiber als Miniporttreiber der Portklasse (PortCls) implementieren. Der Audiotreiber funktioniert in Verbindung mit dem Portcls-Systemtreiber (Portcls.sys), der eine integrierte Komponente von Windows ist.

Im Vergleich zu anderen Geräteklassen ist das Audiosubsystem hinsichtlich der Art und Weise einmalig, in der es die Energieverwaltung ausführt, wenn sich die Plattform im verbundenen Standbyenergiezustand befindet (das heißt, wenn der Bildschirm deaktiviert ist). Wenn die Plattform sich im verbundenen Standbymodus befindet, kann das System Töne erzeugen, um den Benutzer in Echtzeit über Ereignisse (z. B. das Eintreffen einer neuen E-Mail) zu benachrichtigen. Darüber hinaus kann der Benutzer das Display des Systems ausschalten und weiterhin von einer Anwendung wiedergegebene Klänge hören. Diese Funktionen lassen sich nicht durch eine einfache Energieverwaltungsstrategie erreichen, in der das Audiosubsystem deaktiviert werden muss, wenn sich das System im verbundenen Standbymodus befindet. Stattdessen muss die Energieverwaltung des Audiosubsystems zur Laufzeit auf Leerlaufbasis ausgeführt werden (sodass es nur bei Bedarf aktiviert wird), außer wenn das System sich im Zustand „ACPI Shutdown (S5)“ befindet.

Der Audiotreiber führt die Energieverwaltung auf Leerlaufbasis zur Laufzeit in enger Kooperation mit der Windows-Audioinfrastruktur und dem PortCls-Systemtreiber aus. PortCls überwacht alle Zugriffe (z. B. E/A- und Eigenschaftszugriffe) des Audiogeräts und setzt den Leerlauftimer bei jedem Zugriff zurück. Wenn der Leerlauftimer abläuft, überführt PortCls das Audiogerät (mit Hilfe des Audiotreibers) in einen Standbyzustand mit geringem Energiebedarf (D3). Im Fall einer neuen Zugriffsaktivität versetzt PortCls das Audiogerät wieder in den aktiven Zustand (D0).

PortCls registriert sich auch beim Windows Power Framework (PoFx), sodass das Power-Engine-Plug-In (PEP) des Systems über die Änderung des Energiezustands des Audiogeräts benachrichtigt werden kann. Dank dieser Benachrichtigungen weiß das PEP, wann es Taktsignale und Power-Rails sicher deaktivieren kann, die möglicherweise von den Audioverarbeitungseinheiten und anderen SoC-Funktionsblöcken gemeinsam genutzt werden.

Empfehlung: Wenn das Audiosubsystem nicht verwendet wird, sollte es sich im Ruhezustand befinden, in dem es insgesamt weniger als ein Milliwatt verbraucht. Diese Gesamtmenge umfasst die von den Audioverarbeitungseinheiten, dem Off-SoC-Codec und allen weiteren Audioschaltungen (z. B. Verstärker für Lautsprecher und Kopfhörer) verbrauchte Energie.

Hardwaretopologie des Audiosubsystems

Das Audio-Subsystem besteht aus mehreren On-SoC- und Off-SoC-Komponenten, wird Windows jedoch als einzelnes Gerät im ACPI-Namespace präsentiert.

Die Audioverarbeitungseinheiten befinden sich auf dem SoC. SoCs von verschiedenen Anbietern umfassen Audioverarbeitungseinheiten, die in ihrer Funktionalität, ihrem Stromverbrauch und ihrer Leistung variieren. Die Audioverarbeitungseinheiten lagern Audiofunktionen aus: Sie verarbeiten Audiodatenströme (z. B. durch Mischen und Anwenden von Audioeffekten) ohne den Hauptprozessor. Für die Audiowiedergabe, die nicht latenzempfindlich ist, wird das Auslagern von Audiofunktionen aus dem Hauptprozessor bevorzugt, da die Audioverarbeitungseinheiten weniger Energie verbrauchen als der Hauptprozessor.

Weitere Informationen zum Auslagern von Audiofunktionen finden Sie unter Audioverarbeitung mit Hardwareauslagerung.

Das System enthält auch einen Off-SoC-Audiocodec, der den digitalen Audiodatenstrom in die analoge Ausgabe für integrierte Lautsprecher oder externe Kopfhörer umwandelt. Der Codec kann integrierte analoge Verstärker für Lautsprecher und Kopfhörer enthalten. Stattdessen können auch eigenständige Verstärker verwendet werden. Ein typischer Codec weist die folgenden Verbindungen mit der On-SoC-Audioverarbeitungseinheit auf:

• Eine digitale Audioschnittstelle (I2S oder ein ähnlicher serieller Bus).
• Eine Steuerungsschnittstelle (in der Regel I2C oder ein ähnlicher serieller Bus).
• Mindestens ein GPIO-Pin zum Steuern der Energieverwaltungsschaltungen und zum Unterbrechen des SoC, wenn sich der Codeczustand ändert.

Diese Verbindungen werden im folgenden Blockdiagramm gezeigt.

Aus der Sicht von Windows bilden die Audioverarbeitungseinheit und der Audiocodec zusammen das Audiogerät. Das Audiogerät muss im ACPI-Namespace als einzelnes Geräteobjekt aufgezählt werden.

Das Audiosubsystem sollte zwar über einen einzigen Audiotreiber für Windows verfügbar gemacht werden, aber der SoC-Anbieter kann optional ein Treibererweiterungsmodell verwenden, in dem der Audiotreiber in zwei oder mehr separate Treiber unterteilt ist. Beispielsweise kann die Steuerungssoftware, die den Audiocodec direkt verwaltet, in einem Codectreiber platziert sein, der vom Hauptaudiotreiber getrennt ist. Der Hauptaudiotreiber verwaltet den Codec dann indirekt, indem er mit dem Codectreiber kommuniziert. Die Details eines solchen Treibererweiterungsmodells können im Rahmen dieses Dokuments nicht erläutert werden und gelten speziell für den Audiotreiber des jeweiligen SoC-Anbieters. Der Systemintegrator sollte direkt mit dem SoC-Chipanbieter zusammenarbeiten, um solche proprietären Funktionen im Audiosubsystem zu implementieren.

Energieverwaltungsmodi

Das Audiosubsystem muss die folgenden beiden Energieverwaltungsmodi unterstützen:

• Ein aktiver Modus, in dem Audiodatenströme aktiv für den Benutzer gesendet werden.
• Ein Ruhemodus mit geringem Energiebedarf, in dem die Audioverarbeitungseinheit deaktiviert ist, der Off-SoC-Codec in einen Modus mit geringem Energiebedarf versetzt wurde und alle Komponenten des Audiosubsystems zusammen weniger als ein Milliwatt verbrauchen.

In der folgenden Tabelle werden diese beiden Energiemodi beschrieben.

Mode	BESCHREIBUNG	Energiezustand Gerät (Dx)	Durchschnittlicher Stromverbrauch	Beenden der Latenz für aktiv	Übergangsmechanismus
Aktiv (Datenstrom)	Die Audioverarbeitungseinheiten senden aktiv Audiodatenströme, und der Codec liefert analoge oder digitale Audiodaten an einen Audioendpunkt, z. b. einen Kopfhörer, integrierte Lautsprecher oder ein HDMI-Remoteausgabegerät.	D0	<= 100 Milliwatt (Audioverarbeitung + Codec)	–	Übergang zu D0, initiiert durch PortCls. Tritt auf, wenn ein Anwendungs- oder Systemdienst einen Audiodatenstrom initiiert.
Standby	Die Audioverarbeitungseinheiten senden keine Audiodatenströme, und die einzige Aufgabe des Codecs ist es, für ausreichend Standbyleistung zu sorgen, um Anschluss- und Entfernungsereignisse an einer Audiobuchse zu erkennen.	D3	<= 1 Milliwatt (Empfohlen.)	<= 35 Millisekunden oder <= 300 Millisekunden, je nach Systemszenario (Erforderlich.)	Übergang zu D3, initiiert durch PortCls. Tritt auf, wenn alle Anwendungen das Senden von Audiodatenströmen beendet haben und die vom Treiber oder vom System angegebene Leerlaufzeit abläuft.

In einigen SoC-Designs sind die Audioverarbeitungseinheiten Multifunktionsblöcke, die gemeinsam mit Videodecodierung und Grafikverarbeitung genutzt werden. In diesen Designs kann es Szenarien geben, in denen die Audioverarbeitungseinheiten aktiviert werden, auch wenn keine aktiven Audiodatenströme gesendet werden.

Mechanismen der Energieverwaltung durch Software

Der primäre softwaregesteuerte Energieverwaltungsmechanismus für das Audiosubsystem ist die Leerlauferkennung zur Laufzeit, die in PortCls integriert ist. Mit der Leerlauferkennung zur Laufzeit kann PortCls die Aktivität der Anwendung in Bezug auf Audiodatenströme beobachten, um zu ermitteln, wann das Audiogerät zwischen dem aktiven Modus und dem Ruhezustand umgeschaltet werden muss. PortCls ermöglicht außerdem einen proprietären Erweiterungsmechanismus zwischen dem Audiotreiber und dem vom SoC-Anbieter bereitgestellten Power-Engine-Plug-In (PEP), um den Leistungszustand der Audioverarbeitungseinheiten zu verwalten.

Leerlauferkennung zur Laufzeit

Die Komponenten im Audiosubsystem wechseln in den Ruhezustand mit niedrigem Energiebedarf, nachdem das Audiosubsystem für ein bestimmtes Timeoutintervall nicht aktiv war.

Der vom SoC-Anbieter bereitgestellte Audiotreiber muss die folgenden beiden standardmäßigen Timeouteinstellungen für den Leerlauf registrieren:

• PerformanceIdleTime: Dieses Timeoutintervall wird verwendet, wenn die Hardwareplattform an eine Stromversorgung angeschlossen ist.
• ConservationIdleTime: Dieses Timeoutintervall wird verwendet, wenn die Plattform mit Akkuleistung betrieben wird.

Die Timeouteinstellungen für den Leerlauf werden in Registrierungseinträgen gespeichert, die sich im PowerSettings-Registrierungsschlüssel des Audiotreibers befinden. Weitere Informationen finden Sie unter Implementierung von Inaktivitätstimern für Audiogeräteklassen.

Die folgenden INF-Richtlinien müssen verwendet werden, um ein PerformanceIdleTime-Timeout und ein ConservationIdleTime-Timeout von jeweils einer Sekunde festzulegen:

[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 arbeitet mit der Windows-Kernelenergieverwaltung zusammen, um automatisch zwischen den PerformanceIdleTime- und ConservationIdleTime-Timeoutwerten zu wechseln, wenn die Plattform zwischen Netzstromversorgung und Akkuleistung wechselt.

Wenn sich das System im verbundenen Standbymodus befindet (der Bildschirm also deaktiviert ist) und die Audiowiedergabe nicht initiiert ist, verwendet PortCls immer ein Leerlauftimeout von einer Sekunde, unabhängig von der Timeouteinstellung, die der Adaptertreiber in seiner INF-Datei angibt.

Der vom SoC-Anbieter bereitgestellte Audiotreiber muss auch eine IdlePowerState-Einstellung registrieren, um den Energiezustand anzugeben, in den nach Ablauf des Leerlauftimeouts übergegangen werden soll. Auf allen verbundenen Standbyplattformen müssen Audiotreiber D3 als den Energiezustand registrieren, in den gewechselt werden soll, wenn ein Leerlauftimeout auftritt. Um den D3-Zustand anzugeben, legt die AddReg-Richtlinie im vorherigen Beispiel den IdlePowerState-Wert auf 03 fest.

Wenn das Leerlauftimeout abläuft, ruft PortCls die IAdapterPowerManagement3::PowerChangeState3-Methode des Audiotreibers auf, um den Treiber anzuweisen, das Audiogerät auf den Wechsel in den Ruhemodus mit geringem Energiebedarf vorzubereiten (NewPowerState = PowerDeviceD3). Der Audiotreiber muss Kontext für die Audioverarbeitungseinheit speichern und den Codec in einen Ruhemodus mit geringem Energiebedarf versetzen, der durchschnittlich weniger als ein Milliwatt verbraucht. Im Modus mit geringem Energiebedarf muss der Codec genügend Energie beziehen, um Anschluss- und Entfernungsereignisse an einer Audiobuchse zu erkennen und einen durch einen Schwellenwert ausgelösten Interrupt im Hauptprozessor im SoC zu generieren.

Wenn im verbundenen Standbymodus eine Audiowiedergabe aufgrund von Anwendungsstreaming, Systemtongenerierung oder Überwachungsbenachrichtigungen erforderlich ist, ruft PortCls die PowerChangeState3-Methode des Audiotreibers auf, um den Treiber anzuweisen, das Audiogerät so zu konfigurieren, dass es im aktiven Energiezustand D0 (NewPowerState = PowerDeviceD0) ausgeführt wird. Der Audiotreiber muss den Kontext für die Audioverarbeitungseinheit wiederherstellen und den Codec erneut aktivieren.

PortCls ruft die IAdapterPowerManagement3::D3ExitLatencyChanged-Methode des Audiotreibers auf, um den Treiber über einer Änderung bei der maximalen Latenz zu benachrichtigen, die für Übergänge aus dem Ruhezustand (D3) in den aktiven Zustand (D0) toleriert werden kann. PortCls ruft die D3ExitLatencyChanged-Methode des Audiotreibers auf, um die maximale Latenz entweder auf 35 Millisekunden oder auf 300 Millisekunden festzulegen. Der Audiotreiber muss die maximale Latenztoleranz berücksichtigen und darf nicht in einen Zustand mit geringem Energiebedarf wechseln, in dem eine Wiederaufnahmelatenz erforderlich ist, die größer ist als der von PortCls in der D3ExitLatencyChanged-Methode angegebene Wert.

Energieverwaltung im Codec

Der vom SoC-Anbieter bereitgestellte Audiotreiber ist auch für Konfiguration und Energieverwaltung des Off-SoC-Audiocodecs zuständig. Der Treiber steuert den Audiocodec in der Regel über eine SoC-Verbindung mit einem I²C-Bus oder einem anderen einfachen Peripheriebus (Simple Peripheral Bus, SPB). Der Treiber muss auch Interrupts vom Codecgerät verarbeiten.

Der Audiotreiber muss den Codec in einen Ruhemodus mit geringem Energiebedarf versetzen, wenn das Audiosubsystem in den D3-Zustand (Ruhezustand) übergeht.

Der Audiotreiber muss den Codec in den aktiven Energiemodus versetzen, wenn das Audiosubsystem in den D0-Zustand (aktiver Zustand) übergeht.

Windows Power Framework (PoFx) und das Power-Engine-Plug-In (PEP)

PortCls registriert sich beim Windows Power Management Framework, sodass das vom SoC-Anbieter bereitgestellte PEP beim Wechsel von Audiogeräten zwischen dem aktiven Modus (D0) und dem Ruhemodus (D3) benachrichtigt wird. In vielen SoC-Designs werden Taktsignale und Power-Rails für die Audioverarbeitungseinheiten mit anderen SoC-Funktionsblöcken gemeinsam genutzt. Das vom SoC-Anbieter bereitgestellte PEP kennt die SoC-spezifischen Taktsignal- und Energietopologien und führt die entsprechende Aktion zum Anhalten von Taktsignalen und Deaktivieren von Power-Rails aus, die mit der Audioverarbeitungseinheit verknüpft ist, wenn sie sich im Ruhemodus befindet.

Darüber hinaus unterstützt PortCls einen privaten Mechanismus namens Kontextfreigabe, der es dem Audiotreiber ermöglicht, direkt mit dem PEP zu kommunizieren, um eine differenzierte Energieverwaltung durchzuführen. Beispielsweise kann ein Audiotreiber die Kontextfreigabe verwenden, um das PEP über den aktuellen Inhaltstyp und die Bitrate des Audiodatenstroms zu informieren. Das PEP verwendet diese Informationen, um die Taktfrequenz für die Audioverarbeitungseinheit auf das Minimum zu senken, das zum Verarbeiten des aktuellen Audiodatenstroms ohne Störungen erforderlich ist.

Die Kontextfreigabeschnittstelle ist als einfacher Eingabe-/Ausgabepuffer mit einer GUID definiert und ähnelt anderen erweiterbaren Windows Power Management-Schnittstellen. Weitere Informationen zur Kontextfreigabe zwischen dem Miniporttreiber und dem PEP finden Sie unter Private PortCls-Kontextfreigabe für PEP.

Unterstützte Hardwareenergiekonfigurationen

Auf verbundenen Standbyplattformen unterstützt Windows eine einzelne Konfiguration zur Hardwareenergieverwaltung für das Audiosubsystem.

In der erwarteten Konfiguration befinden sich die Audioverarbeitungseinheiten im SoC, und der externe Audiocodec ist über eine SoC-kompatible digitale Audioschnittstelle – einen einfachen Peripheriebus (SPB) wie I²C – und mindestens einen GPIO-Pin mit dem SoC verbunden. Es wird empfohlen, dass der Audiocodec und die externe Logik im Ruhemodus nicht mehr als ein Milliwatt verbrauchen.

Das folgende Blockdiagramm zeigt die erwartete Hardwarekonfiguration, den Audiogerätetreiberstapel und die Komponenten des Benutzermodus.

Im Audiosubsystem können sich hinter dem Codec Komponenten befinden, die für das Betriebssystem und seine Treiber nicht sichtbar sind. Hier kann es sich beispielsweise um Verstärker für Lautsprecher und Kopfhörer handeln. Solche Komponenten sind plattformspezifisch und können vom Systemintegrator innerhalb der Anforderungen ausgewählt werden, die im Rahmen des Windows-Zertifizierungsprogramms beschrieben wurden.

Der Systemintegrator muss das SoC-Audiogerät im Stamm der APCI-Namespacehierarchie aufzählen. Sämtliche Ressourcen für Arbeitsspeicher, E/A, GPIO und I²C (oder einen anderen SPB), die für die Audioverarbeitungseinheit und den externen Codec erforderlich sind, müssen im _CRS-Objekt unter dem Gerät im Namespace aufgelistet sein. Der Systemintegrator und der ACPI-Firmwareentwickler müssen mit dem Audiotreiberentwickler kommunizieren, um die Konventionen für die Reihenfolge von Hardwareressourcen wie z. B. der GPIO-Pins zu verstehen. Beispielsweise unterscheidet ein Treiber, der zwei GPIO-Ressourcen empfängt, zwischen diesen Ressourcen anhand der Reihenfolge, in der sie in der Ressourcenliste angezeigt werden. Weitere Informationen finden Sie unter GPIO-basierte Hardwareressourcen.

Obwohl der ACPI-Treiber (Acpi.sys) die Wechsel zwischen aktivem Modus (D0) und Ruhemodus (D3) beobachten kann, da die Geräteenergie-IRPs durch den Audiostapel gesendet werden, darf der Systemintegrator weder den Audiocodec als Teil einer Energieressource beschreiben noch die ACPI-Steuerungsmethoden „_PS0“ und „_PS3“ verwenden, um den Energiezustand des Codecs zu ändern. Im Ruhemodus wird erwartet, dass der Codec mit ausreichend geringem Energiebedarf funktioniert, sodass er jederzeit eingeschaltet bleiben kann, um Anschluss- und Entfernungsereignisse an einer Audiobuchse zu erkennen.

Der Audiocodec und alle externen Verstärker müssen auf einer Power-Rail platziert werden, die immer Strom führt, außer wenn das System sich im Zustand „ACPI Shutdown (S5)“ befindet. Um die Verstärker nach Bedarf zu aktivieren oder zu deaktivieren, können GPIO-Pins verwendet werden. Die Verstärker können über GPIO-Pins vom Codec oder vom SoC gesteuert werden.

Eine wesentliche Anforderung besteht darin, dass der Codec selbst jederzeit mit Strom versorgt wird – auch wenn er sich im Ruhezustand mit geringem Energiebedarf befindet –, sodass Anschluss- und Entfernungsereignisse an einer Audiobuchse erkannt werden können. Der Codec muss einen Interrupt generieren, der den SoC aus dem Leerlaufzustand reaktivieren kann, um Anschluss- und Entfernungsereignisse an einer Kopfhörerbuchse zu verarbeiten.

Überlegungen zum Reaktivieren (Erkennen von Anschluss- und Entfernungsereignissen an einer Kopfhörer- oder Mikrofonbuchse)

Das Audiosubsystem muss Änderungen am Zustand des Audioausgabegeräts behandeln, die jederzeit auftreten können. Die häufigsten Änderungen am Audiogerätezustand sind das Anschließen eines Ausgabegeräts an die integrierte Kopfhörerbuchse und das Entfernung dieses Geräts aus der Buchse. Diese Anschluss- und Entfernungsereignisse müssen auch bei allen anderen angefügten Audioanschlüssen erkannt werden, einschließlich Anschlüssen für Mikrofon und digitale Signale.

Der Audiostapel muss jederzeit in der Lage sein, Anschluss- und Entfernungsereignisse an einer Audiobuchse zu erkennen. Die Interruptleitung aus dem Audiocodec muss mit einem GPIO-Pin verbunden sein, der immer mit Strom versorgt wird und in der Lage ist, den SoC aus dem Leerlaufzustand zu reaktivieren. Die Buchsenerkennung ermöglicht Windows, aktuelle Informationen über die Audioeingabe- und -ausgabegeräte in Echtzeit bereitzuhalten, einschließlich aller Zeiten, in denen sich das System im verbundenen Standbymodus befindet. Windows wird beispielsweise sofort benachrichtigt, wenn der Benutzer einen Stecker an die Kopfhörerbuchse anschließt. Als Reaktion auf diese Benachrichtigung werden alle zukünftigen Benachrichtigungstöne an den Kopfhörer statt an die integrierten Lautsprecher der Plattform weitergeleitet.

Wie zuvor beschrieben, weist die Systemfirmware dem Audiogerät eine Reihe von Hardwareressourcen zu. Diese Ressourcen werden im ACPI-Objekt „_CRS“ beschrieben, und das Betriebssystem übergibt eine Liste dieser Ressourcen an den Audiotreiber. Diese Ressourcenliste enthält alle GPIO-Interrupts, die verwendet werden, um Zustandsänderungen im Audioausgabegerät zu erkennen (z. B. das Anschließen eines Kopfhörers). Diese Interrupts müssen in der ACPI-Systemfirmware als Reaktivierungsquellen gekennzeichnet werden. Es wird erwartet, dass der Audiotreiber Interrupthandler für jeden dieser Reaktivierungsinterrupts hinzufügt. Die Interrupthandler müssen den Zustand des Audiogeräts, des Audiocodecs und des Audiotreibers entsprechend aktualisieren, basierend darauf, welcher Interrupt signalisiert wurde.

Die Reihenfolge der Ressourcen im _CRS-Objekt basiert auf einer gerätespezifischen Konvention, die vom Audiotreiberentwickler definiert wird. Wenn der Treiber beispielsweise zwei Interruptressourcen empfängt, unterscheidet der Treiber zwischen diesen basierend auf der Reihenfolge, in der sie in der Ressourcenliste auftreten. Der ACPI-Firmwareentwickler muss dieselbe Reihenfolge verwenden, um diese Ressourcen in der ACPI-Firmware zu beschreiben.

Mehrere Hardware-, Firmware- und Softwaresubsysteme müssen zusammenarbeiten, damit die Erkennung von Anschluss- und Entfernungsereignissen an den Audiobuchsen ordnungsgemäß funktioniert. Der Systemintegrator und der Audiotreiberentwickler die den folgenden Implementierungsrichtlinien einhalten:

Hardware und SoC

• Die Audiocodec-Hardware muss Anschluss- und Entfernungsereignisse an Kopfhörer-, Mikrofon- und anderen Audiobuchsen zu allen Zeiten erkennen, in denen das System eingeschaltet ist, einschließlich der Zeiten, in denen sich das System im verbundenen Standbymodus befindet.
• Die Audiocodec-Hardware muss in der Lage sein, Anschluss- und Entfernungsereignisse an der Buchse zu erkennen und dabei nur sehr wenig Strom zu verbrauchen (weniger als ein Milliwatt im Durchschnitt).
• Der Audiocodecinterrupt muss mit einem GPIO-Pin im SoC verbunden sein, der das SoC aus dem Leerlaufzustand reaktivieren kann.

ACPI-Firmware

• Das Audiogerät muss im ACPI-Namespace beschrieben werden.
• Die GPIO-Leitungen, die zum Erkennen eines Anschlussereignisses an einer Audiobuchse verwendet werden, müssen durch die ACPI-Firmware als exklusive Interrupts zum Reaktivieren beschrieben werden. Verwenden Sie das Beschreibungsmakro GpioInt, und legen Sie das Shared-Argument auf „ExclusiveAndWake“ fest.
• Die Hardwareressourcen des Audiogeräts müssen in der Reihenfolge aufgeführt werden, die vom Audiotreiber erwartet wird.

Audiotreibersoftware

• Der Audiotreiber muss einen Interrupthandler mit den GPIO-Reaktivierungsinterrupts verbinden.
• Wenn der Audiotreiber den Interrupt verarbeitet, wertet er den Zustand der Audioeingabe-/-ausgabegeräte aus und führt die entsprechenden Aktionen aus.

Testen und Validieren

Systemintegratoren können Windows Performance Analyzer (WPA) verwenden, um sicherzustellen, dass das Audiogerät die Leerlaufenergieverwaltung und -übergänge zwischen dem aktiven Zustand (D0) und dem Ruhezustand (D3) zur Laufzeit erwartungs- und ordnungsgemäß ausführt. WPA ist auf der Microsoft Connect-Website verfügbar. Wenden Sie sich an Ihren Microsoft-Vertreter, wenn Sie Unterstützung beim Abruf von WPA und den WPA-Erweiterungen zur Energieverwaltung wünschen. Der Systemintegrator sollte auch das WPA-Paket mit Tools zur Energieverwaltungsanalyse abrufen. Dieses Paket enthält Erweiterungen für WPA, die eine systemeigene Energieverwaltungsanalyse ermöglichen.

WPA nutzt die ETW-Instrumentierung (Ereignisablaufverfolgung für Windows), die in den Windows-Kernel und andere Windows-Komponenten integriert ist, einschließlich PortCls. Um die ETW-Ablaufverfolgung zu verwenden, werden verschiedene Ablaufverfolgungsanbietern aktiviert, und ihre Ereignisse werden in einer Protokolldatei aufgezeichnet, während ein Testszenario ausgeführt wird. Wenn das Szenario abgeschlossen ist, werden die Ablaufverfolgungsanbieter beendet. WPA ermöglicht die Nachverarbeitung und visuelle Analyse der Protokolldatei, die vom im Testszenario generiert wird.

Auf einem System, auf dem WPA installiert ist, kann eine Reihe von Befehlen verwendet werden, um Informationen zur Instrumentierung der Energieverwaltung zu sammeln, mit denen sich die Energieverwaltung des Audiogeräts überprüfen lässt. Das Tool „Xperf.exe“ ist im Ordner „\%Program Files%\Windows Kits\8.0\Windows Performance Analyzer“ installiert.

Zum Starten der ETW-Ablaufverfolgung für die Energieverwaltung öffnen Sie ein Eingabeaufforderungsfenster als Administrator, wechseln in das Verzeichnis, das WPA enthält und führen die folgenden Befehle aus:

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

Diese Befehle weisen Windows an, den Microsoft-Windows-Kernel-Power ETW-Ereignisanbieter zu aktivieren und den anfänglichen Zustand von Ereignissen vom Microsoft-Windows-Kernel-Power-Anbieter zu erfassen.

Nachdem die ETW-Ablaufverfolgung gestartet wurde, sollte der Entwickler Systemszenarien ausführen, um zu überprüfen, ob das Audiogerät ordnungsgemäß zwischen dem aktiven Zustand (D0) und dem Ruhezustand (D3) wechselt. Der Entwickler sollte das Audiogerät in den folgenden Szenarien überprüfen:

• Starten Sie eine Anwendung, durch die das Audiogerät vom Zustand D3 in den Zustand D0 übergeht.
• Eine Sekunde nach dem Schließen aller Audioanwendungen geht das Audiogerät von D0 in D3 über.
• Wenn sich das System im verbundenen Standbymodus befindet, bleibt das Audiogerät im Zustand D3.
• Wenn während des verbundenen Standbymodus eine Überwachungsbenachrichtigung generiert wird, wechselt das Audiogerät von D3 zu D0, gibt Audiodaten wieder und kehrt dann nach einer Sekunde zu D3 zurück.

Nachdem diese Testszenarien abgeschlossen wurden, verwenden Sie den folgenden Befehl, um die ETW-Ablaufverfolgungserfassung zu beenden:

>xperf -stop powertracesession -d trace.etl

Verwenden Sie WPA, um die resultierende Trace.etl-Datei zu öffnen. Um WPA über die Befehlszeile zu starten, geben Sie den Befehl Wpa.exe ein.

Wählen Sie im WPA-Tool das Diagramm Dstate Gerät aus der Liste Graph-Explorer aus. Die folgende Ansicht sollte angezeigt werden.

In dieser Ansicht wird ein Gerät entweder durch seinen ACPI-Namen (z. B. „\_SB.AUDI“) oder den Geräteinstanzpfad (z. B.“ ACPI\MSFT0731\4%ffff367&2“) identifiziert. Sowohl der ACPI-Name als auch der Geräteinstanzpfad werden in der Zusammenfassungstabelle für das Diagramm Dstate Gerät aufgeführt.

Um die vom Audiogerät vorgenommenen D-Zustandsübergänge anzuzeigen, suchen Sie den Gerätenamen in der Zusammenfassungstabelle, klicken Sie mit der rechten Maustaste auf den Namen, und wählen Sie Zu Auswahl filtern aus. Das resultierende Diagramm zeigt nur die D-Zustandsübergänge des Audiogeräts, wie im folgenden Screenshot dargestellt.

Diese Beispielablaufverfolgung zeigt, dass sich das Audiogerät während des gesamten Ablaufverfolgungszeitraums im Zustand D3 befand (angegeben durch die Koordinate 3 auf der vertikalen Achse), außer für einen Fünf-Sekunden-Zeitraum ca. 290 Sekunden nach Beginn der Ablaufverfolgung.

Prüfliste für die Energieverwaltung

Systemintegratoren und SoC-Anbieter sollten die folgende Prüfliste verwenden, um sicherzustellen, dass das Energieverwaltungsdesign ihres Audiosubsystems mit Windows 8.1 kompatibel ist.

• Der Systemintegrator sollte bei der Integration von Audiosubsystemgeräten eng mit dem SoC-Anbieter zusammenarbeiten.

• Der vom SoC-Anbieter entwickelte Audiotreiber muss Folgendes ausführen:

  • Festlegen der jeweiligen Leerlauftimeouts zur Laufzeit, wenn das System mit Wechselstrom und mit Akkustrom ausgeführt wird. Der Audiotreiber muss sowohl den PerformanceIdleTime-Wert als auch den ConservationIdleTime-Wert auf eine Sekunde festlegen.

  • Festlegen des IdlePowerState-Werts auf D3.

  • Festlegen von IdlePowerState, PerformanceIdleTime und ConservationIdleTime in der INF-Datei für den Audiotreiber auf die folgenden Werte:

    [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
    

  • Der Audiotreiber muss jeden Kontext der Audioverarbeitungseinheit speichern und den Codec in einen Ruhezustand mit geringem Energiebedarf versetzen, wenn PortCls die IAdapterPowerManagement3::P owerChangeState3-Methode des Treibers mit dem Geräteleistungszustand D3 aufruft.

  • Der Audiotreiber muss den gesamten Kontext der Audioverarbeitungseinheit wiederherstellen und den Codec reaktivieren, wenn PortCls die PowerChangeState3-Methode des Treibers mit dem Geräteleistungszustand D0 aufruft.

  • Der Audiotreiber darf keine Leistungszustände verwenden, die gegen die Anforderung an die Latenz nach Beendigung von D3 verstoßen, die von PortCls in der IAdapterPowerManagement3:D3ExitLatencyChanged-Methode bereitgestellt wird.

  • Der Audiotreiber muss die Konfiguration und Energieverwaltung des externen Codecs verarbeiten.

  • Der Audiotreiber muss durch Schwellenwerte ausgelöste Interrupts vom externen Codec verarbeiten, wenn der Codec das Anschließen oder Entfernen eines Steckers erkennt.

• Der SoC-Anbieter muss ein Power Engine-Plug-In (PEP) bereitstellen, das Folgendes ausführt:

  • Versetzen der Audioverarbeitungseinheiten in einen Zustand mit geringem Energiebedarf, wenn der Audiotreiber in den Ruhezustand (D3) wechselt.
  • Aktivieren aller Taktsignale und Power-Rails, die für die Audioverarbeitungseinheiten erforderlich sind, wenn der Audiotreiber in den aktiven Energiemodus D0 wechselt.
  • Korrektes Skalieren der Taktsignal- und Spannungswerte, die an die Audioverarbeitungseinheit geliefert werden, entsprechend der erforderlichen Ebene der Verarbeitungsaktivität, die sich nach dem Audioformat, dem Inhaltstyp und der Bitrate richtet.

• Um die Hardware- und Firmwareplattform für das Audiosubsystem zu entwickeln, muss der Systemintegrator Folgendes ausführen:

  • Verwenden eines Codecs, der im Ruhemodus weniger als ein Milliwatt verbraucht, aber trotzdem Anschluss- und Entfernungsereignisse an Buchsen erkennen kann.
  • Platzieren des Codecs auf einer System-Power-Rail, die jederzeit aktiviert ist, außer wenn sich das System im Zustand „ACPI Shutdown (S5)“ befindet.
  • Entwerfen der ACPI-Firmware auf eine Weise, dass das Audiosubsystem im Stammverzeichnis der ACPI-Namespacehierarchie als einzelnes Gerät aufgezählt wird.
  • Bestimmen der Konventionen für Arbeitsspeicher, Interrupt, E/A, GPIO und I²C-Ressourcenreihenfolge, die vom Audiotreiber erwartet werden, und Sicherstellen, dass die Ressourcen im ACPI-Objekt „_CRS“ in derselben Reihenfolge aufgeführt werden.

• Um die Energieverwaltung des Audiosubsystems zu testen und zu überprüfen, muss der Systemintegrator Folgendes ausführen:

  • Sicherstellen, dass der Audiotreiber in den Energiezustand D3 wechselt, wenn keine Anwendungen das Audiosubsystem verwenden oder Audiodaten für den Benutzer generieren.
  • Wenn der Wechsel in den Standby aus dem Leerlauf erfolgt ist, überprüfen Sie, ob der Audiotreiber im aktiven D0-Energiezustand bleibt, wenn eine Anwendung oder das System Audio erzeugt (auch während der Audiowiedergabe bei deaktiviertem Bildschirm).
  • Wenn der Wechsel in den Standby durch eine Benutzeraktion erfolgt ist (Drücken des Netzschalters, Schließen des Deckels oder über Startmenü), überprüfen Sie, ob alle Audiostreams aus dem Betriebssystem geschlossen wurden und der Audiotreiber in den D3-Energiezustand wechselt, wenn eine Anwendung oder das System Audio erzeugt (neu in der Betriebssystemversion 24H2).
  • Überprüfen Sie mittels der im Windows Hardware Lab Kit (HLK) bereitgestellten Tests, ob die Audiowiedergabe störungs- und fehlerfrei erfolgt.
  • Sicherstellen, dass die Buchsenerkennung ordnungsgemäß funktioniert, wenn sich das System im verbundenen Standbymodus befindet, und dass Audiodaten ordnungsgemäß an den Kopfhörer oder die Lautsprecher weitergeleitet werden, wenn der Benutzer einen Stecker an die Kopfhörerbuchse anschließt oder daraus entfernt.
  • Messen der Leistung, die von der Audioverarbeitungseinheit, dem externen Codec und allen zusätzlichen analogen Verstärkerschaltungen verbraucht wird. Sicherstellen, dass das gesamte Audiosubsystem weniger als ein Milliwatt verbraucht, wenn es sich im Ruhezustand (D3) befindet.