ACX-IO-Anforderungspaket (IRPs)
Dieses Thema enthält eine Zusammenfassung der Audio Class eXtensions-(ACX-)E/A-Anforderungspakete.
Allgemeine Informationen zu ACX finden Sie unter Übersicht über ACX-Audioklassenerweiterungen und Zusammenfassung von ACX-Objekten. Informationen zu ACX-Zielen und -Synchronisierung finden Sie unter ACX-Ziele und Treibersynchronisierung.
Senden von IRP-Anforderungen
Ein ACX-Client gibt eine Aktion über eine Treiberanforderung (IRP) an. Allgemeine Informationen zu IRPs finden Sie unter E/A-Anforderungspakete und Paketgesteuertes E/A mit wiederverwendbaren IRPs.
Der Client sendet diese Anforderung mithilfe des Schaltkreises oder des Datenstroms an einen Schaltkreis/einen Pin/ein Element/einen Datenstrom. Die Anforderungs-ID ist ein Triplet:
- set (guid),
- id/index (ulong)
- optional pin-id/node-id (ulong) value.
Zur Erstellungszeit kann der Treiber Eigenschaften/Methoden/Ereignisse optional einem der folgenden Objekte zuordnen:
- Pin
- Verbindung
- Datenstrom
- Element
Jede Eigenschaft/Methode/jedes Ereignis wird durch eine ID und einen Rückrufhandler identifiziert. Standardmäßig definiert ACX alle Eigenschaften/Methoden/Ereignisse, die von KS-Clients (Benutzermodusebenen) benötigt werden. Daher müssen Treiber sie nicht neu definieren. Treiber müssen nur ihre benutzerdefinierten Eigenschaften/Methoden/Ereignisse definieren.
Wenn ACX eine IoCtrl-Anforderung im ACX-/KS-Stil empfängt, überprüft sie die Anforderung und sperrt die Puffer des Aufrufers im Arbeitsspeicher. Diese Überprüfung und Puffersperre erfolgt in einem WDM-Vorverarbeitungsrückruf, den ACX zur Initialisierungszeit registriert hat. In dieser Phase fügt ACX dem WDM-IRP einen eigenen Abschlussrückruf hinzu, bevor es zur normalen Verteilung an WDF weitergeleitet wird. Der Abschlussrückruf bietet ACX die Möglichkeit, alle Kompatibilitätsumgehungen nach Bedarf hinzuzufügen/einzufügen.
Als Nächstes ruft WDF den IRP-Rückruf der dynamischen Verteilung auf. In diesem Rückruf verknüpft ACX/der Treiber (optional) eine WDF-Warteschlange mit der Anfrage. In diesem Rückruf lokalisiert ACX das ACX-Zielobjekt: Schaltkreis, Pin, Schaltkreiselement oder Stream anhand des Handles, mit dem diese Anfrage gesendet wurde, und der optionalen Pin-ID/Node-ID/dem Schaltkreiselement innerhalb der Anforderung.
Bei einem zusammengesetzten Audiogerät ist es möglich, dass sich das Zielobjekt (nur Schaltkreis) auf einem anderen Stack befindet als das Objekt, auf dem die Anforderung ursprünglich gesendet wurde. Darüber hinaus muss eine Anforderung möglicherweise auf mehrere Stacks reagieren, ein Beispiel dafür ist ein Datenstromänderungszustand.
Nachdem das Ziel identifiziert wurde, überprüft ACX, ob das Schaltkreis-/Datenstromzielobjekt eine Außerkraftsetzung für die Standardverarbeitungswarteschlange angibt. Ist dies nicht der Fall, verwendet ACX die Standardwarteschlange, die dem aktuellen Handle zugeordnet ist. Der ACX/Treiber weist dann WDF an, die Anforderung entweder in die angegebene oder die Standardwarteschlange einzufügen.
Als nächstes ruft WDF den Rückruf des aufrufenden Prozesses auf, falls vorhanden. ACX benötigt/verwendet den In-Prozessrückruf für die Verarbeitung nicht, da es die Puffer im Speicher bereits im Vorverarbeitungsrückruf gesperrt hat. Daher informiert ACX WDF, den In-Prozessrückruf nicht aufzurufen, nachdem die Zielwarteschlange für die Anforderung angegeben wurde.
Verwendung der sekundären Warteschlange
Die ACX-Standardwarteschlange ist eine stromverwaltete, serielle, keine Sperrwarteschlange. Der Treiber sollte jede Anforderung verschieben, die eine unbestimmte Zeit in eine sekundäre Warteschlange einnimmt. Die vom Treiber verwaltete Warteschlange könnte eine manuell passive Warteschlange sein, in der der Treiber diese Anforderungen erhalten kann, bis sie später abgeschlossen werden können.
Leistungsreferenzanforderungen
ACX schaltet das Gerät automatisch ein, bevor eine Anforderung an den Treiber gesendet wird. Dies erfolgt implizit mithilfe einer verwalteten WDF-Warteschlange. Dadurch wird ein portcls ähnelndes Verhalten erzeugt. Das heißt, es wird eine Leistungsreferenz genommen, bevor die Anforderung abgeschickt wird.
Aufrufen des Verteilerhandlers der Warteschlange
Als Nächstes übernimmt WDF eine Leistungsreferenz und ruft den Verteilerhandler der Warteschlange auf. Die Standardwarteschlange, die dem ACX-Handler zugeordnet ist, sucht nach Vorprozessüberschreibungen, und wenn vorhanden, ruft ACX den Vorverarbeitungsrückruf des registrierten Treibers auf. ACX ermöglicht es dem Treiber, Außerkraftsetzungen basierend auf dem Anforderungstyp (Eigenschaft, Ereignis und Methode) und (optional) Anforderungs-IDs anzugeben.
Wenn ein Vorverarbeitungsrückruf angegeben wurde, befindet sich die Anforderung nach dem Aufrufen des Rückrufs im Besitz des Treibers. Der Treiber kann die Anforderung abschließen oder zur normalen Verteilung an ACX weiterleiten.
Wenn kein Vorverarbeitungsrückruf angegeben wurde oder der Treiber die Anforderung an ACX zurückgibt, ruft ACX das ACX-Zielobjekt ab und sucht den Rückruf der deklarierten Eigenschaft/des Ereignisses/der Methode. Anschließend wird der Rückruf aufgerufen, der die WDF-Anforderung und das ACX-Zielobjekt (Schaltkreis/Datenstrom/Schaltkreiselement) übergibt.
Als Nächstes führt ACX (oder der Treiber bei benutzerdefinierten Eigenschaften) die angeforderte Aktion aus und schließt die Anforderung ab, oder wenn die Anforderung eine unbestimmte Zeit benötigt, kann der Treiber die Anforderung in eine sekundäre Warteschlange verschieben. Der Treiber ist für das Serialisieren und Abschließen aktiver ausstehender Anforderungen verantwortlich.
Dieses Diagramm veranschaulicht den typischen Anforderungsverteilungs-Workflow.
Dieses Diagramm veranschaulicht den Verteilungsworkflow, wenn der Treiber einen ACX-Vorverarbeitungsrückruf definiert hat, obwohl die Anforderung am Ende vom ACX-Framework behandelt wird.
Interne ACX-Schaltkreis-PnP-Schnittstellen
Um die Kommunikation zwischen ACX Endpoint Manager (EM) und den ACX-Treiberkomponenten (Kernelmodus- oder Benutzermoduskomponenten) zu erleichtern, definiert ACX die folgenden internen PnP-Geräteschnittstellen:
- ACXCATEGORY_CIRCUITFACTORY
- ACXCATEGORY_CIRCUIT
Das EM verwendet die ACXCATEGORY_CIRCUITFACTORY-Schnittstelle, um ein Zielgerät anzuweisen, um einen bestimmten Schaltkreis dieses Typs zu erstellen oder zu entfernen. Diese Schnittstelle ist aktiv, während das unterstrichene Gerät Schaltkreise erstellen kann, andernfalls ist sie deaktiviert (Beispiel: Entfernen, Überraschungsentfernung, Beenden oder manuelles Entfernen).
Das Audio-Subsystem verwendet ACXCATEGORY_CIRCUIT (die auf einem anderen Geräte-Stack als dem Schaltkreis-Manager-Stack erstellt werden können), um den ACX-Schaltkreis nachzuverfolgen und zu kommunizieren. Diese Schnittstelle ist aktiv, wenn der Schaltkreis erstellt wurde und bereit für die Verarbeitung von Befehlen ist.
Informationen zu anderen Strom- und PnP-Prozessen finden Sie unter ACX-Geräteenumeration und ACX-Energieverwaltung.
Weitere Informationen
Übersicht über ACX-Audioklassenerweiterungen