Übersicht über ACX-Audioklassenerweiterungen

Artikel
11/14/2023

Dieses Thema enthält eine allgemeine Zusammenfassung der ACX-Audioklassenerweiterungen.

ACX-Framework basiert auf dem Windows-Treiberframework

Damit Audiotreiber zuverlässiger sind und PC-Benutzern die bestmögliche Erfahrung bieten können, ist Audio Class eXtension (ACX) jetzt in der frühen Vorschau verfügbar. ACX definiert eine neue WDF-Klassenerweiterung (Windows Driver Framework) für die Audiodomäne. Weitere Informationen zu WDF finden Sie unter Einführung in Framework-Objekte. Viele WDF-Konzepte, z. B. WDF-E/A-Ziele, sind in ACX verfügbar. Weitere Informationen zu WDF-E/A-Zielen finden Sie unter Einführung in E/A-Ziele.

ACX wird mit dem Kernelmodustreiberframework (KMDF) und nicht mit dem Benutzermodustreiberframework (UMDF) erstellt, um latenzbedingte Wartezeiten zu vermeiden, die mit dem mehrfachen Wechseln von Aufgaben vom Benutzer- in den Kernelmodus während des Streamings verbunden sind. Portcls-Audiotreiber, das aktuelle Legacymodell, sind WDM,Kernelmodus-basierte Treiber.

Die Verwendung des ACX-Frameworks erleichtert das Erstellen von funktionierenden Audiotreibern "out of the box". ACX unterstützt beispielsweise die Standardvervollständigung für die meisten Einstellungen. Dies erleichtert es dem Treiber, die richtige Einstellung zu verwenden, ermöglicht aber dennoch die Anpassung.

Das ACX-Framework macht Audiokonzepte als WDF-Objekte verfügbar, mit denen der Treiber interagieren kann (Stream, Format usw.). Dies ermöglicht eine konsistente Programmiererfahrung und ermöglicht eine größere Community von Audiotreiberentwicklern.

Hinweis

Die ACX-Header und -Bibliotheken sind nicht im WDK 10.0.22621.2428 (veröffentlicht am 24. Oktober 2023) enthalten, sind aber in früheren Versionen sowie in den neuesten (25000-Serienbuilds) Insider Preview des WDK verfügbar. Weitere Informationen zu Vorschauversionen des WDK finden Sie unter Installieren von Vorschauversionen des Windows Driver Kit (WDK).

ACX-Ziele

Die Audioklassenerweiterungen (ACX) haben die folgenden Ziele.

Vereinfachen Sie den Aufwand und das Know-how, die für die Entwicklung einfacher eigenständiger Audiotreiber erforderlich sind.
Reduzieren Sie die Menge an Code, den ein Drittanbieter entwickeln muss. Weniger Codezeilen verringern die Wartung und erleichtern das Debuggen.
Ermöglicht die Ausführung vorhandener Clients im oberen Benutzermodus (Dienste und Apps).
Vereinfachen Sie die Power-pnp-Verwaltung der Audiostapeltreiber.
Keine Auswirkungen auf die Gesamtleistung, d. h. keine zusätzliche/spürbare Latenz.
Vereinfachen Sie den Aufwand für die Entwicklung Multi-Stack Audiotreibern.
Zulassen, dass der Drittanbietertreiber den Sperrmechanismus angeben kann, der beim Streaming verwendet werden soll.
Verwendet die Isolationslösung für die Bereitstellung von Microsoft-Komponenten, die Treiber/APOs-Module eigenständig und wiederverwendbar macht.

ACX-Architektur

Dieses Diagramm veranschaulicht die ACX-Architektur mit vorhandenen Benutzermodus-Apps und ACX-Objekten im Kernelmodus und Audiohardware am unteren Rand des Stapels. Zusätzlich zu den ACX-Objekten hat der Treiberentwickler Zugriff auf die WDF-Objekte, die er im Treibercode nutzen kann, z. B. für die Energieverwaltung.

Diagramm zur Veranschaulichung der ACX-Architektur mit Benutzer- und Kernelmodus mit WDF- und ACX-Objekten im Kernelmodus und Audiohardware am unteren Rand des Stapels.

ACX-Koexistenz mit vorhandenen Audiotreibern

ACX ist für die Koexistenz mit vorhandenen Audiotreibern konzipiert, um eine flexible Migration zu neuen ACX-Treibern zu ermöglichen.

Die binäre Kompatibilität von beendenden, unveränderten (WDM-basierten) Audio-Miniporttreibern wird von vorhandenen Legacytreibern der Windows-Klasse beibehalten.
AcX unterstützt derzeit nur WaveRT-basiertes Streaming.
Ältere PortCls/Ks und neue ACX-Stapel werden parallel ausgeführt. Die Verwendung von ACX erzwingt nicht, dass Drittanbieter ihre aktuellen Audiotreiber auf das neue Modell portieren. Da das Modell viele Vorteile bietet, können sich 3 dritte Parteien freiwillig dafür entscheiden, es für ihre zukünftige Audioentwicklung zu verwenden.

Allgemeine ACX-Definitionen

Leitung : Eine Treiberkomponente, die einen teil- oder vollständigen Audiopfad darstellt. Die Verbindung stellt einen vorhandenen Endpunkt und seine Funktionen dar.

Stream : Eine Treiberkomponente, die erstellt wird, um einen Audiodatenstrom darzustellen, der von einer Verbindung erstellt wird. Der Stream besteht aus einer Liste von Elementen, die basierend auf den Elementen der übergeordneten Schaltung erstellt wurden.

Stream Circuit : Die Leitung in einer Multi-Stack-Architektur (partieller Audiopfad), die direkt mit dem Streamingdienst im oberen Benutzermodus verbunden ist.

Kernschaltung: Die Leitung in einer Multi-Stack Architektur (partieller Audiopfad), die die Identität des Audioendpunktgeräts angibt.

Element : Eine Teilkomponente einer Leitung oder eines Stromstroms, der eine Audiofunktion der Unterstrichshardware darstellt. Dies kann ein Volume-, Stummschalt- oder Jack-Element oder ein Modulelement in einer DSP-Schaltung usw. sein.

Endpunktaudiopfad : Eine einzelne oder Eine Gruppe von Circuit-Objekten, die miteinander verbunden sind, um einen einzelnen Audioendpunkt darzustellen. Die Circuit-Objekte müssen aus verschiedenen Gerätestapeln stammen, die zu demselben oder verschiedenen Treibern gehören.

Zusammenfassung der ACX-Objekte

Eine Zusammenfassung der ACX-Basisobjekte finden Sie unter Zusammenfassung der ACX-Objekte.

ACX-Beispieltreiber

Ein einfacher ACX-Beispieltreiber steht zum Anzeigen und Herunterladen auf GitHub im Entwicklungsbranch https://github.com/microsoft/Windows-driver-samples/tree/develop/audio/Acx/Sampleszur Verfügung: .

Treiberüberprüfung

Die Verwendung der Treiberüberprüfung wird für alle Windows-Treiber empfohlen, einschließlich ACX-Treibern. Verwenden Sie den Treiberprüfer, um latente Fehler anzuzeigen, den Stromverbrauch zu verringern und die Zuverlässigkeit Ihres Treibers zu erhöhen. Weitere Informationen finden Sie unter Treiberüberprüfung.

AcX Multi-Stack-Treiber standardisiert cross communications

Es ist üblich, dass der Audiopfad mehrere Hardwarekomponenten durchläuft, die von verschiedenen Treiberstapeln verarbeitet werden, um ein vollständiges Audioerlebnis zu schaffen. Es ist typisch für ein System, dass die DSP-, CODEC- und AMP-Funktionalität von verschiedenen Audiotechnologieanbietern implementiert wird.

In einer Multi-Stack-Architektur ohne einen klar definierten Standard ist jeder Anbieter gezwungen, seine eigene proprietäre Schnittstelle und ein eigenes Kommunikationsprotokoll zu definieren. Es ist ein Ziel von ACX, die Entwicklung von Multi-Stack Audiotreibern zu erleichtern, indem die Synchronisierung zwischen diesen Stapeln übernommen wird und ein einfaches wiederverwendbares Muster für die Kommunikation von Treibern untereinander bereitgestellt wird.

Weitere Informationen finden Sie unter Treiberübergreifende ACX-Multistapelkommunikation.