ACX-Ziele und Treibersynchronisierung

Dieses Thema enthält eine Zusammenfassung der ACX-Ziele (Audio Class eXtensions) und der Treibersynchronisierung.

Allgemeine Informationen zu ACX finden Sie unter ACX-Audioklassenerweiterungen – Übersicht und Zusammenfassung von ACX-Objekten. Informationen zu IRPs finden Sie unter ACX-E/A-Anforderungspaket-IRPs.

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

ACX verwendet WdfIoTarget , um die Kommunikation zwischen ACX-Objekten, Schaltungen, Pins, Streams, Elementen und Leitungsfabriken zu erleichtern. WdfIoTarget ist eine vorhandene WDF-Abstraktion, um die Kommunikation zwischen zwei verschiedenen Stapeln zu erleichtern.

Treiber verwenden AcxTargetCircuit , um mit einer Remoteverbindung zu kommunizieren, die von einem anderen Stapel verfügbar gemacht wird. AcxTargetCircuit wird mithilfe eines WdfIoTarget implementiert.

Treiber verwenden AcxTargetPin , um mit dem Pin einer Remoteschaltung zu kommunizieren, der von einem anderen Stapel verfügbar gemacht wird. AcxTargetPin wird mithilfe eines WdfIoTarget implementiert, um Nachrichten an die Remote-Pin-Entität zu senden.

Treiber verwenden AcxTargetStream , um mit dem Stream einer Remoteschaltung zu kommunizieren, der von einem anderen Stapel verfügbar gemacht wird. AcxTargetStream wird mithilfe eines WdfIoTarget implementiert, um einen Remotestream zu erstellen und den Status des Remotestreams zu ändern.

Treiber verwenden AcxTargetElement , um mit dem Element einer Remoteschaltung zu kommunizieren, das von einem anderen Stapel verfügbar gemacht wird. AcxTargetElement wird mithilfe eines WdfIoTarget implementiert, um Nachrichten an die Remoteelemententität zu senden.

Treiber verwenden AcxTargetFactoryCircuit, um mit einer Remote circuit Factory instance zu kommunizieren. AcxTargetFactoryCircuit wird mithilfe eines WdfTarget implementiert, um Nachrichten an die Remoteschaltungsfactory zu senden.

Für die Interaktion mit der Remoteverbindung unterstützt jeder der oben aufgeführten ACX-Typen:

• properties
• methods
• events

Alle diese Typen basieren auf den WdfIoTarget-Objekttypen .

Dieses Diagramm zeigt die ACX-Zielarchitektur und die Vererbung aus den WDF-Treiber- und Geräteobjekten.

ACX-Treibersynchronisierung und Serialisierung

Der Begriff Synchronisierung ist ein allgemeiner Begriff und wird verwendet, um auf die Vorgänge zu verweisen, die zum Freigeben von Ressourcen (Arbeitsspeicher, E/A usw.) zwischen mehreren gleichzeitigen Clients erforderlich sind.

Der Begriff Serialisierung wird verwendet, um auf einen Synchronisierungstyp für einen Objekttyp (E/A-Anforderungen, Rückrufe usw.) zu verweisen.

ACX-Treiber sind WDF-Treiber, was bedeutet, dass die Synchronisierung von ACX-Treibern auf den Synchronisierungsfunktionen von WDF basiert:

• Die Verwendung der Verweisanzahl und des hierarchischen Objektmodells.
• Vom Treiber konfigurierbare Ablaufsteuerung für E/A-Warteschlangen.
• Objektpräsentationssperre für Geräteobjekte und E/A-Warteschlangen.
• Automatische Serialisierung von Plug & Play und Stromrückrufen.

Eine ausführliche Beschreibung der Synchronisierung und Serialisierung finden Sie unter Verwenden der automatischen Synchronisierung. Eine ausführlichere Erläuterung finden Sie im Microsoft Press Book Developing Drivers with Windows Driver Foundation (Entwickeln von Treibern mit Windows Driver Foundation ).

WDF unterstützt die folgenden Synchronisierungsbereiche:

• Kein Bereich (Standard in KMDF).
• Gerätebereich: WDF ruft die Geräteobjektpräsentationssperre ab, um Vorgänge zu serialisieren.

Die ACX-Standardwarteschlange ist eine passive, serielle Warteschlange ohne Sperren. Der Treiber muss den E/A-Vorgang abschließen, bevor der nächste übermittelt wird.

ACX unterstützt die Option "Warteschlangenbereich" nicht. Mit dieser Option serialisiert der Treiber E/A in einer bestimmten Warteschlange. Verschiedene Warteschlangen können unterschiedliche Synchronisierungsbereiche aufweisen.

ACX unterstützt die Serialisierung des Gerätebereichs nicht. Standardmäßig serialisiert ACX Anforderungen mithilfe einer seriellen E/A-Warteschlange ohne Sperren. Jede Verbindung und jedes Streamobjekt verfügt über eine eigene dedizierte Warteschlange. Weitere Informationen zu Streaming-E/A finden Sie im Thema ACX-Streaming.

Wenn ein Treiber über eine Sperre verfügt, sollte er nie (explizit oder implizit) Code außerhalb seiner Kontrolle aufrufen, bis die Sperre aufgehoben wird.

Als Verlaufsreferenz verwendet die ursprüngliche PortCls einen Synchronisierungsbereich wie die WDF-Gerätebereichssynchronisierung, bei der alle E/A-Vorgänge für alle auf diesem Gerät erstellten Audiountergeräte dieselbe Serialisierungssperre durchlaufen. Diese Art der Serialisierung war und ist die Ursache für verschiedene Störungen. In höheren Versionen von Windows 10 (Version 1511 – TH2) wurde PortCls aktualisiert, um eine andere Sperre für E/A-Anforderungen der Streamposition zu verwenden.

Weitere Informationen

Übersicht über ACX-Audioklassenerweiterungen

Zusammenfassung von ACX-Objekten

ACX-Versionsinformationen

ACX-Referenzdokumentation

Treiberübergreifende ACX-Multistapelkommunikation