ACX-Ziele und Treibersynchronisierung
Dieses Thema enthält eine Zusammenfassung der Audio Class eXtensions-(ACX-)Ziele und der Treibersynchronisierung.
Allgemeine Informationen zu ACX finden Sie unter Übersicht über ACX-Audioklassenerweiterungen und Zusammenfassung von ACX-Objekten. Informationen zu IRPs finden Sie unter ACX-IO-Anforderungspaket (IRPs).
ACX-Ziele
ACX verwendet WdfIoTarget, um die Kommunikation zwischen ACX-Objekten, Schaltkreisen, Pins, Datenströmen, Elementen und Schaltkreis-Factorys zu erleichtern. WdfIoTarget ist eine bestehende WDF-Abstraktion, um die Kommunikation zwischen zwei verschiedenen Stacks zu erleichtern.
Treiber verwenden AcxTargetCircuit, um mit einem Remoteschaltkreis zu kommunizieren, der von einem anderen Stack bereitgestellt wird. AcxTargetCircuit wird mithilfe eines WdfIoTarget implementiert.
Treiber verwenden AcxTargetPin, um mit dem Pin eines Remoteschaltkreises zu kommunizieren, der von einem anderen Stack bereitgestellt wird. AcxTargetPin wird mithilfe eines WdfIoTarget implementiert, um Nachrichten an die Remote-Pin-Entität zu senden.
Treiber verwenden AcxTargetStream, um mit dem Stream eines Remoteschaltkreises zu kommunizieren, der von einem anderen Stack bereitgestellt 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 eines Remoteschaltkreises zu kommunizieren, das von einem anderen Stack bereitgestellt wird. AcxTargetElement wird mithilfe eines WdfIoTarget implementiert, um Nachrichten an die Remoteelemententität zu senden.
Treiber verwenden AcxTargetFactoryCircuit, um mit einer Remoteschaltkreis-Factory-Instanz zu kommunizieren. AcxTargetFactoryCircuit wird mithilfe eines WdfTarget implementiert, um Nachrichten an die Remoteschaltkreis-Factory zu senden.
Um mit dem Remoteschaltkreis zu interagieren, unterstützt jeder der oben aufgeführten ACX-Typen Folgendes:
- properties
- Methoden
- events
Alle diese Typen basieren auf dem WdfIoTarget-Objekt.
Dieses Diagramm zeigt die ACX-Zielarchitektur und die Vererbung von WDF-Treiber- und Geräteobjekten.
ACX-Treibersynchronisierung und Serialisierung
Der Begriff „Synchronisierung“ ist allgemeiner Natur 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.
Die Begriffs „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 von Referenzzahlen und das hierarchische Objektmodell.
- Treiberkonfigurierbare Flusssteuerung für E/A-Warteschlangen.
- Objektpräsentationssperre für Geräteobjekte und E/A-Warteschlangen.
- Automatische Serialisierung von Plug and 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-Buch Developing Drivers with Windows Driver Foundation (Entwicklung von Treibern mit Windows Driver Foundation).
WDF unterstützt die folgenden Synchronisierungsbereiche:
- Kein Bereich (Standard in KMDF).
- Gerätebereich, WDF erhält die Geräteobjektpräsentationssperre zum Serialisieren von Vorgängen.
Die ACX-Standardwarteschlange ist eine passive serielle Warteschlange ohne Sperrung. Der Treiber muss den E/A-Vorgang abschließen, bevor der nächste geliefert wird.
ACX unterstützt die Warteschlangenbereichsoption nicht. Mit dieser Option serialisiert der Treiber E/A in einer bestimmten Warteschlange. Verschiedene Warteschlangen weisen möglicherweise unterschiedliche Synchronisierungsbereiche auf.
ACX unterstützt keine Serialisierung des Gerätebereichs. Standardmäßig serialisiert ACX Anforderungen mithilfe einer seriellen E/A-Warteschlange ohne Sperrung. Jedes Schaltkreis- und Datenstromobjekt verfügt über eine eigene dedizierte Warteschlange. Weitere Informationen zum Streaming-E/A finden Sie im Thema „ACX Streaming“.
Wenn ein Treiber eine Sperre enthält, sollte er niemals Code außerhalb des Steuerelements aufrufen (explizit oder implizit), bis die Sperre freigegeben wird.
Für die Verlaufsreferenz verwendet die ursprüngliche PortCls einen Synchronisierungsbereich wie die WDF-Gerätebereichssynchronisierung, wobei alle E/A für alle auf diesem Gerät erstellten Audiountergeräte dieselbe Serialisierungssperre durchlaufen. Diese Art der Serialisierung war und ist immer noch die Ursache verschiedener Störungen. In späteren Versionen von Windows 10 (Version 1511 – TH2) wurde PortCls aktualisiert, um eine andere Sperre für E/A-Anforderungen für die Datenstromposition zu verwenden.
Weitere Informationen
Übersicht über ACX-Audioklassenerweiterungen