Übersicht über ACX-Audioklassenerweiterungen

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

ACX-Framework basiert auf dem Windows Driver Framework

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

ACX wird mit dem Kernel mode Driver Framework (KMDF) und nicht mit dem Benutzermodustreiberframework (UMDF) erstellt, um zu vermeiden, dass während des Streamings mehrfach Latenzen auftreten, die mit dem Wechsel zwischen Dem Benutzer und Kernel verbunden sind. Portcls audio drivers, the current legacy model, are WDM, kernel mode based drivers.

Die Verwendung des ACX-Frameworks erleichtert das Erstellen von funktionierenden Audiotreibern "out of the box". AcX unterstützt z. B. den Standardabschluss 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 Programmierung und ermöglicht eine größere Community von Audiotreiberentwicklern.

ACX-Ziele

Die Audioklassenerweiterungen (ACX) haben die folgenden Ziele.

  • Vereinfachen Sie den Aufwand und das Know-how, das zum Entwickeln einfacher eigenständiger Audiotreiber erforderlich ist.
  • Verringern Sie die Menge an Code, den ein Drittanbieter entwickeln muss. Weniger Codezeilen verringern die Wartung und vereinfachen 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 von Audiotreibern mit mehreren Stapeln.
  • Zulassen, dass Drittanbietertreiber den Sperrmechanismus angeben, der beim Streaming verwendet werden soll.
  • Verwendet die Lö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, die vorhandene Benutzermodus-Apps und ACX-Objekte im Kernelmodus und Audiohardware am unteren Rand des Stapels zeigt. Zusätzlich zu den ACX-Objekten hat der Treiberentwickler Zugriff auf die WDF-Objekte, um die Vorteile in ihrem Treibercode zu nutzen, z. B. für die Energieverwaltung.

Diagramm, das die ACX-Architektur veranschaulicht und den Benutzer- und Kernelmodus mit WDF- und ACX-Objekten im Kernelmodus und Audiohardware am unteren Rand des Stapels zeigt.

ACX-Koexistenz mit vorhandenen Audiotreibern

ACX ist so konzipiert, dass es mit vorhandenen Audiotreibern gemeinsam vorhanden ist, um eine flexible Migration zu neuen ACX-Treibern zu ermöglichen.

  • Die binäre Kompatibilität des Beendens, unveränderter (WDM-basierter) Audiominiporttreiber wird von vorhandenen älteren Windows-Klassentreibern verwaltet.
  • Nur WaveRT-basiertes Streaming wird derzeit von ACX unterstützt.
  • Ältere PortCls/Ks und neue ACX-Stapel werden nebeneinander ausgeführt. Die Verwendung von ACX erzwingt nicht, dass Drittanbieter ihre aktuellen Audiotreiber in das neue Modell portieren. Da das Modell viele Vorteile bietet, können sich 3. Dritte freiwillig dafür entscheiden, sie für ihre zukünftige Audioentwicklung zu verwenden.

Allgemeine ACX-Definitionen

Schaltkreis – Eine Treiberkomponente, die einen teilweisen oder vollständigen Audiopfad darstellt. Der Schaltkreis stellt einen vorhandenen Endpunkt und seine Funktionen dar.

Stream – Eine Treiberkomponente, die erstellt wird, um einen Audiodatenstrom darzustellen, der von einem Circuit erstellt wird. Der Stream besteht aus einer Liste von Elementen, die basierend auf den Elementen des übergeordneten Schaltkreises erstellt wurden.

Stream-Schaltkreis – der Schaltkreis in einer Multistapelarchitektur (partieller Audiopfad), die direkt mit dem Streamingdienst für den oberen Benutzermodus zusammenarbeiten.

Core Circuit – Der Schaltkreis in einer Multistapelarchitektur (partieller Audiopfad), der die Identität des Audioendpunktgeräts angibt.

Element – Ein Unterkomponente eines Schaltkreises oder Streams, der eine Audiofunktion der Unterstreichungshardware darstellt. Dies kann ein Volume-, Stummschalt- oder Jack-Element oder ein Modulelement auf einem DSP-Schaltkreis 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 denselben oder unterschiedlichen Treibern gehören.

Zusammenfassung von ACX-Objekten

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

AcX-Beispieltreiber

Ein einfacher ACX-Beispieltreiber steht zum Anzeigen und Herunterladen auf GitHub in der Develop Branch https://github.com/microsoft/Windows-driver-samples/tree/develop/audio/Acx/Samples- zur Verfügung.

Driver Verifier

Die Verwendung der Treiberüberprüfung wird für alle Windows-Treiber empfohlen, einschließlich ACX-Treibern. Verwenden Sie die Treiberüberprüfung, 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 behandelt werden, um eine vollständige Audioumgebung zu erstellen. Es ist typisch, dass ein System die DSP-, CODEC- und AMP-Funktionalität von verschiedenen Audiotechnologieanbietern implementiert hat.

In einer Multistapelarchitektur ohne einen klar definierten Standard wird jeder Anbieter gezwungen, sein eigenes proprietäres Schnittstellen- und Kommunikationsprotokoll zu definieren. Es ist ein Ziel von ACX, die Entwicklung von Multi-Stack-Audiotreibern zu erleichtern, indem die Synchronisierung zwischen diesen Stapeln übernommen und ein einfaches wiederverwendbares Muster für Treiber miteinander kommuniziert wird.

Weitere Informationen finden Sie unter ACX multi stack cross driver communications.

Referenzdokumentation zur ACX

Informationen zur ACX-Referenzdokumentation auf Kopfzeilenebene finden Sie in der ACX-Referenzdokumentation.

Weitere Informationen

Zusammenfassung von ACX-Objekten

Referenzdokumentation zur ACX

ACX-Versionsinformationen

ACX-Protokollierung und Debugging

ACX-Ziele und Treibersynchronisierung

ACX IO-Anforderungspaket-IRPs

ACX-Geräteenumeration

ACX-Energieverwaltung

Treiberübergreifende ACX Multi-Stack-Kommunikationen

ACX-Streaming