Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieses Thema enthält eine Zusammenfassung der Ziele der Audioklasse eXtensions (ACX) 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-IO-Anforderungspaket-IRPs.
ACX-Ziele
ACX verwendet WdfIoTarget , um die Kommunikation zwischen ACX-Objekten, Schaltkreisen, Pins, Datenströmen, Elementen und Schaltkreisfabriken zu erleichtern. WdfIoTarget ist eine vorhandene WDF-Abstraktion, um die Kommunikation zwischen zwei verschiedenen Stapeln zu erleichtern.
Treiber verwenden AcxTargetCircuit-, um mit einer Remoteschaltung 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, die 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 Datenstrom einer Remoteschaltung zu kommunizieren, der von einem anderen Stapel verfügbar gemacht wird. AcxTargetStream wird mithilfe eines WdfIoTarget implementiert, um einen Remotedatenstrom zu erstellen und den Status des Remotedatenstroms 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- für die Kommunikation mit einer Remoteschaltungsinstanz. AcxTargetFactoryCircuit wird mithilfe eines WdfTarget implementiert, um Nachrichten an die Fabrik für ferngesteuerte Schaltungen zu senden.
Um mit der Remoteschaltung zu interagieren, unterstützt jeder der oben aufgeführten ACX-Typen Folgendes:
- Eigenschaften
- Methodik
- Ereignisse
Alle diese Typen basieren auf den WdfIoTarget-Objekttypen .
Dieses Diagramm zeigt die ACX-Zielarchitektur und die Vererbung von WDF-Treiber- und Geräteobjekten.
ACX-Treibersynchronisierung und Serialisierung
Der Begriff Synchronisation ist ein allgemeiner Begriff und wird verwendet, um auf die Vorgänge hinzuweisen, die erforderlich sind, um Ressourcen (Speicher, I/O usw.) zwischen mehreren gleichzeitigen Clients zu teilen.
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 der Verweisanzahl und des hierarchischen Objektmodells.
- Treiberkonfigurierbare Flusskontrolle für E/A-Warteschlangen.
- Objektpräsentationssperre für Geräteobjekte und E/A-Warteschlangen.
- Automatische Serialisierung von Plug- und 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 unter " Developing Drivers with Windows Driver Foundation Microsoft Press Book".
WDF unterstützt die folgenden Synchronisierungsbereiche:
- Kein Gültigkeitsbereich (Standard in KMDF).
- Gerätebereich, WDF erhält die Geräteobjektpräsentationssperre zum Serialisieren von Vorgängen.
Die Standard-ACX-Warteschlange ist eine passive serielle Warteschlange ohne Sperrung. Der Treiber muss den E/A-Vorgang abschließen, bevor der nächste verarbeitet 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 Abschnitt "ACX Streaming".
Wenn ein Treiber eine Sperre hält, sollte er niemals (weder explizit noch implizit) Code außerhalb seiner Kontrolle aufrufen, bis die Sperre freigegeben wird.
Zur historischen Referenz verwendet das ursprüngliche PortCls einen Synchronisationsbereich ähnlich der Synchronisation im WDF-Gerätebereich, wobei alle E/A für alle auf diesem Gerät erstellten Audiountergeräte dieselbe Synchronisations-Sperre 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 Streamposition zu verwenden.
Siehe auch
Übersicht über ACX-Audioklassenerweiterungen