IRPs für ACX-E/A-Anforderungspakete

Dieses Thema enthält eine Zusammenfassung der A/A-Anforderungspaket-IRPs für audio Class eXtensions (ACX).

Allgemeine Informationen zu ACX finden Sie unter ACX-Audioklassenerweiterungen – Übersicht und Zusammenfassung der ACX-Objekte. Informationen zu ACX-Zielen und zur Synchronisierung finden Sie unter ACX-Ziele und Treibersynchronisierung.

Hinweis

Die ACX-Header und -Bibliotheken sind nicht im WDK 10.0.22621.2428 (veröffentlicht am 24. Oktober 2023) enthalten, sondern sind in früheren Versionen sowie in den neuesten Insider Preview-Versionen des WDK verfügbar. Weitere Informationen zu Vorschauversionen des WDK finden Sie unter Installieren von Vorschauversionen des Windows Driver Kit (WDK).

IRP-Anforderungsverteilung

Ein ACX-Client gibt eine Aktion über eine Treiberanforderung (IRP) an. Allgemeine Informationen zu IRPs finden Sie unter E/A-Anforderungspakete und Paketgesteuerte E/A-E/A mit wiederverwendbaren IRPs.

Der Client sendet diese Anforderung mithilfe des Leitungs- oder Streamhandles an eine Verbindung/ein Pin/Element/Stream. Die Anforderungs-ID ist ein Triplet:

• set (guid),
• id/index (ulong)
• optionaler Pin-ID/node-ID-Wert (ulong).

Zur Erstellungszeit kann der Treiber Eigenschaften/Methoden/Ereignisse optional einem der folgenden Objekte ordnet:

• 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 für KS-Clients (Benutzermodusebenen) erforderlich sind, sodass Treiber diese nicht neu definieren müssen. Treiber müssen nur ihre benutzerdefinierten Eigenschaften/Methoden/Ereignisse definieren.

Wenn ACX eine IoCtrl-Anforderung im ACX/KS-Stil empfängt, überprüft es die Anforderung und sperrt die Puffer des Aufrufers im Arbeitsspeicher. Diese Überprüfung und Puffersperre erfolgt in einem WDM-Vorprozessrückruf, den ACX zur Initialisierungszeit registriert hat. In dieser Phase fügt acX dem WDM-IRP einen eigenen Abschlussrückruf hinzu, bevor er für die normale Verteilung wieder an WDF weitergeleitet wird. Der Abschlussrückruf gibt ACX die Möglichkeit, bei Bedarf Kompatibilitätsumgehungen hinzuzufügen bzw. einzufügen.

Als Nächstes ruft WDF den IRP-Rückruf des dynamischen Dispatchs auf. In diesem Rückruf ordnet ACX/Driver (optional) der Anforderung eine WDF-Warteschlange zu. In diesem Rückruf sucht ACX das ACX-Zielobjekt: circuit, pin, circuit-element or stream using the handle, an dem diese Anforderung gesendet wurde, und das optionale pin-id/node-id/circuit-element innerhalb der Anforderung.

In einem zusammengesetzten Audiogerät ist es möglich, dass sich das Zielobjekt (nur Leitung) auf einem anderen Stapel befindet als der, für den die Anforderung ursprünglich gesendet wurde. Darüber hinaus muss eine Anforderung möglicherweise auf mehrere Stapel reagieren, ein Beispiel hierfür ist ein Streamänderungszustand.

Nachdem das Ziel identifiziert wurde, überprüft ACX, ob die Zielleitung/das Streamobjekt eine Überschreibung für die Standardverarbeitungswarteschlange angibt. Andernfalls verwendet ACX die Standardwarteschlange, die dem aktuellen Handle zugeordnet ist. Der ACX/-Treiber weist WDF dann an, die Anforderung in die angegebene oder die Standardwarteschlange einzufügen.

Als Nächstes ruft WDF den Prozessrückruf des Aufrufers auf, falls vorhanden. ACX benötigt/verwendet den Aufrufer-Prozessrückruf nicht, da die Puffer im Vorprozessrückruf bereits im Arbeitsspeicher gesperrt sind. Daher informiert ACX WDF, den prozessinternen Rückruf nicht aufzurufen, nachdem die Zielwarteschlange für die Anforderung angegeben wurde.

Sekundäre Warteschlangennutzung

Die ACX-Standardwarteschlange ist eine vom Strom verwaltete, serielle, nicht sperrende Warteschlange. Der Treiber sollte jede Anforderung in unbestimmter Zeit in eine sekundäre Warteschlange verschieben. Die vom Treiber verwaltete Warteschlange kann eine manuell-passive Warteschlange sein, in der der Treiber diese Anforderungen so lange anhalten kann, bis er bereit ist, sie später abzuschließen.

Energiereferenzanforderungen

ACX schalten das Gerät automatisch ein, bevor eine Anforderung an den Treiber weitergeleitet wird. Dies geschieht implizit mithilfe einer von WDF power verwalteten Warteschlangen. Dadurch entsteht ein Verhalten, das portcls ähnelt. Das heißt, vor dem Senden der Anforderung wird ein Energieverweis erstellt.

Aufrufen des Dispatchhandlers der Warteschlange

Als Nächstes übernimmt WDF einen Energieverweis und ruft den Dispatchhandler der Warteschlange auf. Die Standardwarteschlange, die dem ACX-Handler zugeordnet ist, überprüft alle Vorprozessüberschreibungen, und falls vorhanden, ruft ACX den Vorprozessrückruf des registrierten Treibers auf. ACX ermöglicht es dem Treiber, Außerkraftsetzungen basierend auf dem Typ der Anforderung (Eigenschaft, Ereignis und Methode) und (optional) der Anforderungs-IDs anzugeben.

Wenn ein Vorprozessrückruf angegeben wurde, ist die Anforderung im Besitz des Treibers, nachdem ACX den Rückruf aufgerufen hat. Der Treiber kann die Anforderung abschließen oder zur normalen Verteilung zurück an ACX weiterleiten.

Wenn kein Vorprozessrü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 (circuit/stream/circuit-element) übergibt.

Als Nächstes führt ACX (oder für benutzerdefinierte Eigenschaften der Treiber) die angeforderte Aktion aus und schließt die Anforderung ab. Wenn die Anforderung eine unbestimmte Zeit in Anspruch nimmt, kann der Treiber die Anforderung in eine sekundäre Warteschlange verschieben. Der Treiber ist für das Serialisieren und Abschließen aller aktiven ausstehenden Anforderungen verantwortlich.

Dieses Diagramm veranschaulicht den typischen Anforderungsversandworkflow.

Dieses Diagramm veranschaulicht den Verteilungsworkflow, wenn für den Treiber ein ACX-Vorverarbeitungsrückruf definiert ist, obwohl die Anforderung am Ende vom ACX-Framework verarbeitet wird.

Interne PnP-Schnittstellen der ACX-Leitung

Um die Kommunikation zwischen ACX Endpoint Manager (EM) und den ACX-Treiberkomponenten (Kernelmodus- oder Benutzermoduskomponenten) zu erleichtern, definiert die ACX die folgenden internen PnP-Geräteschnittstellen:

• ACXCATEGORY_CIRCUITFACTORY
• ACXCATEGORY_CIRCUIT

Die EM verwendet die ACXCATEGORY_CIRCUITFACTORY-Schnittstelle, um ein Zielgerät anzuweisen, eine bestimmte Leitung dieses Typs zu erstellen oder zu entfernen. Diese Schnittstelle ist aktiv, während das Unterstreichungsgerät Leitungen erstellen kann, andernfalls ist es deaktiviert (Beispiel: Entfernen, Überraschendes Entfernen, Beenden oder manuelles Entfernen).

Das Audio-Subsystem verwendet ACXCATEGORY_CIRCUIT (die möglicherweise auf einem anderen Gerätestapel als der Leitungs-Manager-Stapel erstellt werden), um die ACX-Leitung nachzuverfolgen und mit ihnen zu kommunizieren. Diese Schnittstelle ist aktiv, wenn die Verbindung erstellt wurde und bereit für die Verarbeitung von Befehlen ist.

Informationen zu anderen Power- und PnP-Prozessen finden Sie unter ACX-Geräteaufzählung und ACX-Energieverwaltung.

Weitere Informationen

ACX-Audioklassenerweiterungen – Übersicht

ACX-Referenzdokumentation

Zusammenfassung der ACX-Objekte

ACX-Versionsinformationen

Treiberübergreifende ACX-Multistapelkommunikation