elaborazione audio Hardware-Offloaded
L'elaborazione audio con offload hardware consente l'esecuzione delle principali attività di elaborazione audio all'esterno della CPU principale del computer.
L'elaborazione audio può essere molto impegnativa a livello di calcolo. Pertanto, in molti scenari, può essere utile consentire a un processore dedicato di occuparsi di attività di elaborazione come, ad esempio, la combinazione e l'applicazione di effetti.
Quando si implementa un driver per l'audio scaricato, si sviluppa un driver in grado di elaborare flussi audio offloaded e di esporre tale capacità al sistema audio Windows.
Gli argomenti seguenti in questa sezione illustrano lo sviluppo di driver, l'impatto dell'applicazione e altri problemi da tenere presenti quando si sviluppa un driver audio per una scheda audio che implementa un motore audio hardware per gestire i flussi audio scaricati.
Implementazione del driver audio offloaded hardware
Interfacce helper per l'elaborazione audio offloaded
Segnalazione degli errori per l'audio offloaded
Per informazioni sulle API offloaded, vedere Effetti APO offloaded hardware
Panoramica dell'architettura di elaborazione audio di Hardware-Offloaded
Motore audio software
Il diagramma seguente mostra il motore audio del software Windows.
I flussi audio arrivano nel motore audio software dal livello DELL'API sessione audio di Windows (WASAPI) e possibilmente tramite un'API di livello superiore, ad esempio Media Foundation. Gli effetti del flusso del motore audio software (SFX) possono essere applicati in base al flusso prima che i flussi separati vengano misti e quindi passati attraverso tutti gli effetti endpoint disponibili (EFX) e inviati all'hardware e agli altoparlanti per il rendering.
Motore audio hardware
Il motore audio hardware viene implementato nella scheda audio e rispecchia in gran parte la funzionalità del motore audio software. Anche se Windows supporta l'elaborazione audio caricata dall'hardware, il driver audio per una determinata scheda audio è responsabile dell'esposizione delle funzionalità sottostanti dell'hardware audio, usando la topologia illustrata nel diagramma seguente.
Il motore audio hardware deve accettare un singolo flusso di processo host e fino a n flussi offloaded. Questi flussi offloaded vengono instradati direttamente dal livello dell'applicazione da elaborare nell'hardware. In altre parole, i flussi offloaded non verranno passati attraverso il motore audio software. Il diagramma mostra un'implementazione progettata per gestire fino a tre flussi offloaded. Il flusso del processo host è l'output finale del mixer software di tutti i flussi elaborati nel motore audio software. Ogni motore audio hardware deve contenere anche un mixer hardware.
Per mantenere la parità con il motore audio software e l'interfaccia WASAPI, è necessario che il motore audio hardware fornisca il flusso di output audio finale allo stack audio sotto forma di un flusso di loopback. Ciò è particolarmente critico per le applicazioni e gli scenari che si basano sull'annullamento dell'eco acustica, che richiede la conoscenza del flusso di output finale per annullare gli eco e impedire il feedback.
Per implementare un percorso per un flusso di loopback, il driver audio è responsabile dell'esposizione di un pin di loopback. Questo pin restituirà i dati audio dall'output finale del motore audio, se i dati vengono codificati in un formato PCM. In caso contrario, verrà restituito il risultato della post-combinazione (ma pre-codifica). Ciò significa che nel caso di dati audio elaborati con un hardware EFX che codifica in un formato non PCM, il flusso di loopback viene eseguito direttamente dopo il mixer hardware, prima della fase EFX nel motore audio hardware. Per informazioni sulla topologia del filtro KS che rappresenta il motore audio hardware, vedere Implementazione del driver audio scaricato hardware.
Architettura audio integrata
Il diagramma seguente mostra una panoramica dell'architettura risultante quando un motore audio hardware funziona con il motore audio software Windows.
In uno scenario in cui il driver audio ha indicato il supporto per l'elaborazione audio offloaded, i primi n (in questo caso, tre) flussi inizializzati verranno instradati direttamente dal livello WASAPI al motore audio hardware, ignorando il motore audio software. Tutti i nuovi flussi audio successivi a n supportati dal motore audio hardware verranno instradati tramite il motore audio software per l'elaborazione. Il flusso risultante dal motore audio software viene quindi inviato al motore audio hardware come flusso del processo host. Il flusso del processo host viene misto con i primi n flussi, viene applicata l'elaborazione EFX e il flusso risultante viene quindi inviato agli altoparlanti.
Topologia del filtro KS
In Windows 8 e sistemi operativi successivi è stato fornito il supporto per un motore audio hardware su scheda per elaborare i flussi audio audio. Quando si sviluppa una scheda audio di questo tipo, il driver audio associato deve esporre questo fatto al sistema audio in modalità utente in modo specifico, in modo che il sistema audio possa individuare, utilizzare ed esporre correttamente le funzionalità di questa scheda e il relativo driver.
Per consentire ai driver audio di esporre le funzionalità hardware di queste nuove schede audio, Windows 8 ha introdotto una topologia di filtro KS che il driver deve usare:
Come illustrato nella figura precedente, una topologia di filtro KS rappresenta i percorsi dei dati attraverso l'hardware e mostra anche le funzioni disponibili in tali percorsi. Nel caso di una scheda audio in grado di elaborare l'audio offloaded, sono presenti gli input e gli output seguenti (denominati pin) nel filtro KS:
Un pin del processo host. Rappresenta l'input nel filtro KS dal motore audio software.
Un pin loopback. Questo rappresenta un output dal motore audio hardware al livello DELL'API sessione audio (WASAPI) di Windows.
Un certo numero di pin audio offloaded. Anche se la figura mostra un solo pin di questo tipo, un IHV è gratuito per implementare qualsiasi numero (n) di pin.
Il servizio effettivo nel sistema audio in modalità utente che "conduce" all'individuazione della scheda audio e del relativo driver, è AudioEndpointBuilder. Il servizio AudioEndpointBuilder monitora la classe KSCATEGORY_AUDIO per gli arrivi e le rimozioni dell'interfaccia del dispositivo. Quando un driver di dispositivo audio registra una nuova istanza della classe di interfaccia del dispositivo KSCATEGORY_AUDIO , viene attivata una notifica di arrivo dell'interfaccia del dispositivo. Il servizio AudioEndpointBuilder rileva la notifica di arrivo dell'interfaccia del dispositivo e usa un algoritmo per esaminare la topologia dei dispositivi audio nel sistema in modo che possa intraprendere un'azione appropriata.
Quando sviluppi il driver audio per supportare un adattatore in grado di elaborare l'audio scaricato, il driver deve usare l'endpoint audio KSNODETYPE_AUDIO_ENGINE per esporre le funzionalità del motore audio hardware. Per altre informazioni sul processo di individuazione degli endpoint audio, vedere Algoritmo di Generatore di endpoint audio.
Considerazioni sull'interfaccia utente
È stato sviluppato il driver audio per controllare le funzionalità hardware sottostanti di una scheda audio in grado di elaborare l'audio scaricato. Ciò significa che il driver ha la migliore conoscenza di come controllare le funzionalità dell'adattatore. È quindi necessario sviluppare un'interfaccia utente che esponga le funzionalità dell'adattatore all'utente finale sotto forma di opzioni che possono selezionare, abilitare e/o disabilitare.
Se, tuttavia, hai già un'interfaccia utente usata per controllare gli oggetti di elaborazione audio (APO) sviluppati, questa interfaccia utente potrebbe essere estesa per lavorare con la nuova scheda audio. In questo caso, le estensioni all'interfaccia utente forniscono il controllo software per le API e il controllo hardware per la scheda.
Impatto dell'applicazione
La funzionalità descritta per questo nuovo tipo di adattatore audio e il driver associato può essere usata dalle app UWP tramite WASAPI, Media Foundation, Media Engine o i tag audio> HTML 5<. Tieni presente che Wave e DSound non possono essere usati, perché non sono disponibili per le app UWP. Si noti anche che le applicazioni desktop non possono usare le funzionalità di offload di adattatori audio che supportano l'offload hardware dell'audio. Queste applicazioni possono comunque eseguire il rendering dell'audio, ma solo tramite il pin host che usa il motore audio software.
Se un'app UWP trasmette contenuti multimediali e usa Media Foundation, Media Engine o i tag audio> HTML 5<, l'app viene automaticamente acconsentita all'offload hardware purché la categoria audio appropriata sia stata impostata per il flusso. Il consenso esplicito per l'offload hardware viene eseguito in base al flusso.
Le app UWP che usano le comunicazioni WASAPI o di streaming devono acconsentire esplicitamente all'offload hardware.