Nota
L'accesso a questa pagina richiede l'autorizzazione. Puoi provare ad accedere o a cambiare directory.
L'accesso a questa pagina richiede l'autorizzazione. Puoi provare a cambiare directory.
L'elaborazione audio scaricata dall'hardware consente di eseguire le principali attività di elaborazione audio all'esterno della CPU principale del computer.
L'elaborazione audio può essere molto impegnativa a livello di calcolo. Quindi, 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 scaricati 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 flussi audio scaricati.
Implementazione del driver audio con offload hardware
Interfacce helper per l'elaborazione audio scaricata
Segnalazione dei glitch per l'audio trasferito
Per informazioni sugli APO esternalizzati, vedere Effetti APO scaricati dall'hardware
Panoramica dell'architettura di elaborazione audio Hardware-Offloaded
Motore audio del software
Il diagramma seguente illustra il motore audio software Windows.
I flussi audio arrivano nel motore audio software dal livello WASAPI (Audio Session API) di Windows e possibilmente tramite un'API di livello superiore, ad esempio Media Foundation. Gli effetti del flusso del motore audio software (SFX) possono essere applicati su base per flusso prima che i flussi separati vengano mescolati e quindi elaborati da qualsiasi effetto endpoint disponibile (EFX) e inviati all'hardware di rendering e agli altoparlanti.
Motore audio hardware
Il motore audio hardware viene implementato nella scheda audio e rispecchia in gran parte la funzionalità del motore audio software. E 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 deviati. Questi flussi scaricati vengono instradati direttamente dal livello applicativo per l'elaborazione nell'hardware. In altre parole, i flussi scaricati non verranno passati attraverso il motore software audio. Il diagramma mostra un'implementazione progettata per gestire fino a tre flussi scaricati. Il flusso del processo host rappresenta l'output finale del mixer software di tutti i flussi che sono stati 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 flusso di loopback. Ciò è particolarmente importante per le applicazioni e gli scenari che si basano su Acoustic Echo Cancellation, che richiede la conoscenza del flusso di output finale per annullare le eco e impedire il feedback.
Per implementare un percorso per un flusso di loopback, il driver audio è responsabile di rendere disponibile 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 acquisito 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 sull'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.
Diagramma dei motori audio software e hardware integrati, con l'applicazione che effettua chiamate agli effetti SFX, MFX ed EFX, connessa ai driver, all'hardware audio e al flusso di loopback che riporta al livello WASAPI.
In uno scenario in cui il driver audio ha indicato il supporto per l'elaborazione audio scaricata, i primi n (in questo caso, tre) flussi inizializzati verranno indirizzati 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 attraverso 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
Nei sistemi operativi Windows 8 e versioni successive è stato fornito il supporto per un motore audio hardware su scheda per elaborare i flussi audio. Quando si sviluppa un adattatore 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 un adattatore audio capace di elaborare audio offloaded, vi sono i seguenti input e output (denominati pin) sul filtro KS:
Un pin host del processo. Rappresenta l'input al filtro KS dal motore audio del software.
Un pin loopback. Questo rappresenta un output dal motore audio hardware al livello dell'API di sessione audio di Windows (WASAPI).
Numero di pin audio delegati. Anche se la figura mostra un solo pin di questo tipo, un IHV è libero di 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 azioni appropriate.
Quando si sviluppa 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
Il driver audio è stato sviluppato per controllare le funzionalità hardware sottostanti di una scheda audio in grado di elaborare l'audio scaricato. Ciò significa che il driver ha le migliori conoscenze su come controllare le funzionalità dell'adattatore. È quindi necessario sviluppare un'interfaccia utente che esporrà le funzionalità dell'adapter 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 (API) 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 l'adattatore.
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 Non è possibile usare Wave e DSound, perché non sono disponibili per le app UWP. Si noti anche che le applicazioni desktop non possono usare le funzionalità di offload di schede audio che supportano l'audio scaricato dall'hardware. 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 abilitata per l'offload hardware purché sia stata impostata la categoria audio appropriata per il flusso. La scelta di utilizzare l'offload hardware si fa su base per flusso.
Le app UWP che usano le comunicazioni WASAPI o di streaming devono acconsentire esplicitamente all'offload hardware.