Paquets de demandes d'E/S ACX IRP

Cette rubrique fournit un résumé des extensions de classe audio (ACX) pour les paquets de requêtes d'E/S IRP.

Pour obtenir des informations générales sur ACX, consultez la vue d’ensemble des extensions de classe audio ACX et résumé des objets ACX. Pour plus d’informations sur les cibles et la synchronisation ACX, consultez les cibles ACX et la synchronisation des pilotes.

Envoi des demandes IRP

Un client ACX spécifie une action via une demande de pilote (IRP). Pour obtenir des informations générales sur les IRPs, voir les paquets de demandes d’E/S et Packet-Driven E/S avec des IRP réutilisables.

Le client envoie cette requête à un circuit/broche/élément/flux en utilisant le descripteur du circuit ou du flux. L’ID de requête est un triplet :

• ensemble (guid)
• id/index (ulong)
• valeur facultative pin-id/node-id (ulong).

Au moment de la création, le pilote peut éventuellement associer des propriétés/méthodes/événements à l’un des objets suivants :

• pin
• circuit
• ruisseau
• élément

Chaque propriété/méthode/événement est identifié par un ID et un gestionnaire de rappel. Par défaut, ACX définit toutes les propriétés/méthodes/événements requis par les clients KS (couches en mode utilisateur), de sorte que les pilotes n’ont pas besoin de les redéfinir. Les pilotes doivent uniquement définir leurs propriétés/méthodes/événements personnalisés.

Quand ACX reçoit une requête IoCtrl de style ACX/KS, elle valide la requête et verrouille les mémoires tampons de l’appelant. Cette validation et ce verrou de mémoire tampon sont effectués dans un callback de pré-traitement WDM qu'ACX a enregistré lors de l'initialisation. Pendant cette phase, ACX ajoute son propre rappel d’achèvement à l’IRP WDM avant de le transférer vers WDF pour la répartition normale. Le rappel d’achèvement offre à ACX la possibilité d’ajouter/injecter toutes les solutions de contournement de compatibilité en fonction des besoins.

Ensuite, WDF appelle l'appel de rappel d'IRP de répartition dynamique. Dans cet appel, ACX/driver peut éventuellement associer une file d'attente WDF à la requête. Dans ce rappel, ACX localise l'objet ACX cible : circuit, broche (pin), élément de circuit (circuit-element) ou flux, en utilisant le handle sur lequel cette requête a été envoyée, et l'identifiant facultatif pin-id/node-id/circuit-element dans la requête.

Dans un périphérique composite audio, il est possible que l’objet cible (circuit uniquement) soit situé sur une pile de protocoles différente de celle sur laquelle la requête est envoyée à l’origine. En outre, une demande peut avoir besoin d’agir sur plusieurs piles, comme par exemple un changement d'état du flux.

Une fois la cible identifiée, ACX vérifie si le circuit/l’objet de flux cible spécifie un remplacement pour la file d’attente de traitement par défaut, sinon, ACX utilise la file d’attente par défaut associée au handle actuel. AcX/driver demande ensuite à WDF d’insérer la requête dans la file d’attente spécifiée ou par défaut.

La fonction WDF suivante appelle le rappel de processus in-caller s’il est présent. ACX n’a pas besoin/n’utilise pas le rappel de processus "in-caller", car il a déjà verrouillé les mémoires tampons lors du rappel avant le processus. Par conséquent, ACX informe WDF de ne pas appeler le rappel en cours de processus après avoir spécifié la file d’attente cible pour la requête.

Utilisation de la file d’attente secondaire

La file d’attente ACX par défaut est une file d’attente à alimentation gérée, série et sans verrouillage. Le pilote doit déplacer toute requête prenant un temps indéterminé vers une file d'attente secondaire. La file d’attente gérée par le pilote peut être une file d’attente passive manuelle, où le pilote peut conserver ces demandes jusqu'à ce qu'il soit prêt à les traiter ultérieurement.

Demandes de référence de puissance

ACX active automatiquement l’appareil avant de distribuer une demande au pilote. Cette opération est effectuée implicitement à l’aide de files d’attente gérées par la gestion de l'alimentation WDF. Cela crée un comportement similaire à portcls. Autrement dit, une référence de puissance est prise avant d'envoyer la demande.

Appel du gestionnaire de dispatch de la file d'attente

Ensuite, WDF prend une référence de puissance et appelle le gestionnaire de file d'attente. La file d’attente par défaut associée au gestionnaire ACX vérifie les remplacements avant processus et, le cas échéant, ACX appelle le rappel de préprocesseur du pilote inscrit. ACX permet au pilote de spécifier des remplacements en fonction du type de requête (propriété, événement et méthode) et (éventuellement) des ID de requête.

Si un rappel de pré-processus a été spécifié, une fois que ACX appelle le rappel, la requête appartient au pilote. Le pilote peut terminer la requête ou la renvoyer à ACX pour la répartition normale.

Si un rappel de pré-processus n’a pas été spécifié ou si le pilote renvoie la requête à ACX, ACX récupère l’objet ACX cible et localise le rappel de la propriété/événement/méthode déclaré. Il appelle ensuite le callback qui transmet la requête WDF et l'objet ACX cible (circuit/flux/élément de circuit).

AcX suivant (ou pour les propriétés personnalisées, le pilote) effectue l’action demandée et termine la requête, ou si la demande prend un certain temps, le pilote peut déplacer la requête vers une file d’attente secondaire. Le pilote est responsable de la sérialisation et du traitement des demandes actives en attente.

Ce diagramme illustre le flux de travail standard de répartition des demandes.

Ce diagramme illustre le flux de travail de distribution lorsque le pilote a un rappel de prétraitement ACX défini, bien qu’à la fin, la requête soit gérée par l’infrastructure ACX.

Interfaces internes PnP du circuit ACX

Pour faciliter la communication entre ACX Endpoint Manager (EM) et les composants du pilote ACX (composants en mode noyau ou en mode utilisateur), ACX définit les interfaces d’appareil PnP internes suivantes :

• ACXCATEGORY_CIRCUITFACTORY
• ACXCATEGORY_CIRCUIT

L’em utilise l’interface ACXCATEGORY_CIRCUITFACTORY pour indiquer à un appareil cible de créer ou de supprimer un circuit spécifique de ce type. Cette interface est active alors que l'appareil en question est en mesure de créer des circuits, sinon il est désactivé (par exemple : retrait, retrait imprévu, arrêt ou retrait manuel).

Le sous-système audio utilise ACXCATEGORY_CIRCUIT (qui peut être créé sur une pile d’appareils différente de la pile du gestionnaire de circuits), pour suivre et communiquer avec le circuit ACX. Cette interface est active lorsque le circuit a été créé et prêt à traiter les commandes.

Pour plus d’informations sur les autres processus d’alimentation et PnP, consultez l’énumération des appareils ACX et la gestion de l’alimentation ACX.

Voir aussi

Vue d’ensemble des extensions de classe audio ACX

Documentation de référence relative à l’interface de ligne de commande

Résumé des objets ACX

Informations de version ACX

Communications entre pilotes multiplateformes ACX