IRP della richiesta di I/O ACX
In questo argomento viene fornito un riepilogo degli IRP della richiesta di I/O della classe audio (ACX).
Per informazioni generali su ACX, vedere Panoramica delle estensioni della classe audio ACX e Riepilogo degli oggetti ACX. Per informazioni sulle destinazioni e sulla sincronizzazione di ACX, vedere Destinazioni ACX e sincronizzazione dei driver.
Invio di richieste IRP
Un client ACX specifica un'azione tramite una richiesta di driver (IRP). Per informazioni generali sui runtime di integrazione, vedere Pacchetti di richieste di I/O e I/O basati su pacchetti con IRP riutilizzabili.
Il client invia questa richiesta a un circuito, un pin,un elemento o un flusso usando il circuito o l'handle di flusso. L'ID richiesta è un triplo:
- set (guid),
- id/index (ulong)
- valore pin-id/node-id (ulong) facoltativo.
Al momento della creazione, il driver può facoltativamente associare proprietà/metodi/eventi a uno degli oggetti seguenti:
- pin
- circuito
- stream
- Elemento
Ogni proprietà,metodo/evento è identificato da un ID e da un gestore di callback. Per impostazione predefinita, ACX definisce tutte le proprietà/metodi/eventi richiesti dai client KS (livelli in modalità utente), pertanto i driver non devono ridefinirli. I driver devono definire solo le proprietà o i metodi/eventi personalizzati.
Quando ACX riceve una richiesta IoCtrl in stile ACX/KS, convalida la richiesta e blocca i buffer del chiamante in memoria. Questa convalida e il blocco del buffer vengono eseguiti in un callback di pre-processo WDM registrato in fase di inizializzazione. Durante questa fase, ACX aggiunge il proprio callback di completamento a WDM IRP prima di inoltrarlo a WDF per il normale invio. Il callback di completamento offre a ACX l'opportunità di aggiungere/inserire eventuali soluzioni alternative di compatibilità in base alle esigenze.
Successivamente WDF richiama il callback IRP dispatch dinamico, in questo callback ACX/driver (facoltativamente) associa una coda WDF alla richiesta. In questo acx di callback individua l'oggetto ACX di destinazione: circuito, pin, elemento circuito o flusso usando l'handle in cui è stata inviata la richiesta e l'elemento pin-id/node-id/circuit-element facoltativo all'interno della richiesta.
In un dispositivo composito audio è possibile che l'oggetto di destinazione (solo circuito) si trovi in uno stack diverso da quello in cui viene originariamente inviata la richiesta. Inoltre, potrebbe essere necessario che una richiesta agisca su più stack, un esempio di questo è uno stato di modifica del flusso.
Dopo aver identificato la destinazione, ACX controlla se il circuito di destinazione/oggetto stream-object specifica un override per la coda di elaborazione predefinita, in caso contrario, ACX usa la coda predefinita associata all'handle corrente. AcX/driver indica quindi a WDF di inserire la richiesta nella coda specificata o predefinita.
Successivamente WDF richiama il callback del processo in caller, se presente. ACX non richiede/usa il callback del processo in caller perché ha già bloccato i buffer in memoria nel callback pre-processo. Pertanto, ACX informa WDF di non richiamare il callback in-process dopo aver specificato la coda di destinazione per la richiesta.
Utilizzo della coda secondaria
La coda ACX predefinita è una coda gestita dall'alimentazione, seriale e senza blocco. Il driver deve spostare qualsiasi richiesta che richieda un periodo di tempo non determinato in una coda secondaria. La coda gestita del driver potrebbe essere una coda manuale-passiva, in cui il driver può tenere premuto a queste richieste fino a quando non è pronto per completarli in un secondo momento.
Richieste di riferimento per il risparmio di energia
ACX attiva automaticamente il dispositivo prima di inviare una richiesta al driver. Questa operazione viene eseguita in modo implicito usando code di risparmio energia WDF. In questo modo viene creato un comportamento simile a portcls. Vale a dire, viene preso un riferimento di potenza, prima di inviare la richiesta.
Richiamo del gestore di invio della coda
Il data factory successivo accetta un riferimento di potenza e richiama il gestore di distribuzione della coda. La coda predefinita associata al gestore ACX verifica la presenza di override del pre-processo e, se presente, ACX richiama il callback pre-processo del driver registrato. ACX consente al driver di specificare sostituzioni in base al tipo di richiesta (proprietà, evento e metodo) e (facoltativamente) agli ID richiesta.
Se è stato specificato un callback pre-processo, dopo che ACX richiama il callback, la richiesta è di proprietà del driver. Il driver può completare la richiesta o inoltrarla di nuovo ad ACX per l'invio normale.
Se non è stato specificato un callback pre-processo o se il driver restituisce la richiesta ad ACX, ACX recupera l'oggetto ACX di destinazione e individua il callback di proprietà/evento/metodo dichiarato. Richiama quindi il callback passando la richiesta WDF e l'oggetto ACX di destinazione (circuit/stream/circuit-element).
Successivamente ACX (o per le proprietà personalizzate, il driver) esegue l'azione richiesta e completa la richiesta oppure se la richiesta richiede un periodo di tempo non determinato, il driver può spostare la richiesta in una coda secondaria. Il driver è responsabile della serializzazione e del completamento di eventuali richieste in sospeso attive.
Questo diagramma illustra il tipico flusso di lavoro di invio delle richieste.
Questo diagramma illustra il flusso di lavoro dispatch quando il driver dispone di un callback di pre-elaborazione ACX definito, anche se alla fine la richiesta viene gestita dal framework ACX.
Interfacce interne del circuito ACX PnP
Per facilitare la comunicazione tra ACX Endpoint Manager (EM) e i componenti del driver ACX (componenti in modalità kernel o in modalità utente), ACX definisce le interfacce del dispositivo PnP interne seguenti:
- ACXCATEGORY_CIRCUITFACTORY
- ACXCATEGORY_CIRCUIT
EM usa l'interfaccia ACXCATEGORY_CIRCUITFACTORY per indicare a un dispositivo di destinazione di creare o rimuovere un circuito specifico di questo tipo. Questa interfaccia è attiva mentre il dispositivo sottolineato è in grado di creare circuiti, altrimenti è disabilitato (ad esempio, rimozione, rimozione a sorpresa, arresto o rimozione manuale).
Il sottosistema Audio usa ACXCATEGORY_CIRCUIT (che può essere creato in uno stack di dispositivi diverso da quello dello stack di gestione circuiti), per tenere traccia e comunicare con il circuito ACX. Questa interfaccia è attiva quando il circuito è stato creato e pronto per elaborare i comandi.
Per informazioni su altri processi di alimentazione e PnP, vedere enumerazione dei dispositivi ACX e risparmio energia ACX.
Vedi anche
Panoramica delle estensioni della classe audio ACX
Documentazione di riferimento su ACX