Componenti audio in modalità utente
In Windows Vista, le API audio principali fungono da base del sottosistema audio in modalità utente. Le API audio principali vengono implementate come un sottile livello di componenti di sistema in modalità utente che separano i client in modalità utente da driver audio in modalità kernel e hardware audio. API audio di livello superiore, ad esempio DirectSound e le funzioni multimediali di Windows, accedono ai dispositivi audio tramite le API audio principali. Inoltre, alcune applicazioni audio comunicano direttamente con le API audio di base.
Le API audio di base supportano la nozione intuitiva di un dispositivo endpoint audio. Un dispositivo endpoint audio è un'astrazione software che rappresenta un dispositivo fisico manipolato direttamente dall'utente. Esempi di dispositivi endpoint audio sono altoparlanti, cuffie e microfoni. Per altre informazioni, vedere Dispositivi endpoint audio.
Il diagramma seguente mostra le API audio principali e la relativa relazione con gli altri componenti audio in modalità utente in Windows Vista.
Per semplicità, il diagramma precedente mostra solo un percorso di dati per il rendering audio del dispositivo endpoint, ovvero il diagramma non mostra un percorso dati di acquisizione audio. Le API audio principali includono l'API MMDevice, WASAPI, l'API DeviceTopology e l'API EndpointVolume, implementate nei moduli di sistema Audioses.dll e Mmdevapi.dll modalità utente.
Come illustrato nel diagramma precedente, le API audio principali forniscono una base per le API di livello superiore seguenti:
- Media Foundation
- Funzioni waveXxx e mixerXxx di Windows multimedia
- Directsound
- Direct Musica
DirectSound, le funzioni audio multimediali di Windows e Media Foundation (tramite il suo renderer audio in streaming o il componente SAR) comunicano direttamente con le API audio principali. Direct Musica comunica con le API audio principali indirettamente tramite DirectSound.
Un client di WASAPI passa i dati a un dispositivo endpoint tramite un buffer dell'endpoint. I componenti hardware e software di sistema gestiscono lo spostamento dei dati dal buffer dell'endpoint al dispositivo endpoint in modo che sia in gran parte trasparente per il client. Inoltre, per un dispositivo endpoint che collega un adattatore audio con il rilevamento jack-presence, il client può creare un buffer dell'endpoint solo per un dispositivo endpoint presente fisicamente. Per altre informazioni sul rilevamento della presenza di jack, vedere Dispositivi endpoint audio.
Il diagramma precedente mostra due tipi di buffer dell'endpoint. Se un client di WASAPI apre un flusso in modalità condivisa, il client scrive i dati audio nel buffer dell'endpoint e il motore audio di Windows legge i dati dal buffer. In questa modalità, il client condivide l'hardware audio con altre applicazioni in esecuzione in altri processi. Il motore audio combina i flussi di queste applicazioni e riproduce la combinazione risultante attraverso l'hardware. Il motore audio è un componente di sistema in modalità utente (Audiodg.dll) che esegue tutte le operazioni di elaborazione del flusso nel software. Al contrario, se un client apre un flusso in modalità esclusiva, il client ha accesso esclusivo all'hardware audio. In genere, solo un numero ridotto di applicazioni "audio pro" o RTC richiede la modalità esclusiva. Anche se il diagramma mostra sia i flussi in modalità condivisa che in modalità esclusiva, esiste solo uno di questi due flussi (e il buffer dell'endpoint corrispondente), a seconda che il client apra il flusso in modalità condivisa o in modalità esclusiva.
In modalità esclusiva, il client può scegliere di aprire il flusso in qualsiasi formato audio supportato dal dispositivo endpoint. In modalità condivisa, il client deve aprire il flusso nel formato di combinazione attualmente in uso dal motore audio (o un formato simile al formato di combinazione). I flussi di input del motore audio e la combinazione di output del motore sono tutti in questo formato.
In Windows 7 è stata aggiunta una nuova funzionalità denominata modalità a bassa latenza per i flussi in modalità di condivisione. In questa modalità il motore audio viene eseguito in modalità pull, in cui si verifica una riduzione significativa della latenza. Ciò è molto utile per le applicazioni di comunicazione che richiedono bassa latenza del flusso audio per un flusso più veloce.
Le applicazioni che gestiscono flussi audio a bassa latenza possono usare il servizio MMCSS (Multimedia Class Scheduler Service) in Windows Vista per aumentare la priorità dei thread dell'applicazione che accedono ai buffer degli endpoint. MMCSS consente l'esecuzione di applicazioni audio con priorità alta senza negare le risorse DELLA CPU alle applicazioni con priorità più bassa. MMCSS assegna una priorità a un thread in base al nome dell'attività. Ad esempio, Windows Vista supporta i nomi delle attività "Audio" e "Pro Audio" per i thread che gestiscono flussi audio. Per impostazione predefinita, la priorità di un thread "Pro Audio" è superiore a quella di un thread "Audio". Per altre informazioni su MMCSS, vedere la documentazione di Windows SDK.
Le API audio di base supportano sia i formati di flusso PCM che non PCM. Tuttavia, il motore audio può combinare solo flussi PCM. Pertanto, solo i flussi in modalità esclusiva possono avere formati non PCM. Per altre informazioni, vedere Formati di dispositivo.
Il motore audio viene eseguito nel proprio processo protetto, separato dal processo in cui viene eseguita l'applicazione. Per supportare un flusso in modalità condivisa, il servizio audio di Windows (la casella denominata "Servizio audio" nel diagramma precedente) alloca un buffer dell'endpoint tra processi accessibile sia all'applicazione che al motore audio. Per la modalità esclusiva, il buffer dell'endpoint si trova in memoria accessibile sia all'applicazione che all'hardware audio.
Il servizio audio windows è il modulo che implementa i criteri audio di Windows. I criteri audio sono un set di regole interne che il sistema applica alle interazioni tra flussi audio da più applicazioni che condividono e competono per l'uso dello stesso hardware audio. Il servizio audio di Windows implementa i criteri audio impostando i parametri di controllo per il motore audio. I compiti del servizio audio includono:
- Tenere traccia dei dispositivi audio aggiunti o rimossi dall'utente dal sistema.
- Monitoraggio dei ruoli assegnati ai dispositivi audio nel sistema.
- Gestione dei flussi audio da gruppi di attività che producono classi simili di contenuto audio (console, multimediali e comunicazioni).
- Controllo del livello di volume del flusso di output combinato ("submix") per ognuno dei vari tipi di contenuto audio.
- Informare il motore audio sugli elementi di elaborazione nei percorsi di dati per i flussi audio.
In alcune versioni di Windows, il servizio audio di Windows è disabilitato per impostazione predefinita e deve essere attivato in modo esplicito prima che il sistema possa riprodurre audio.
Nell'esempio illustrato nel diagramma precedente, il dispositivo endpoint è un set di altoparlanti collegati alla scheda audio. L'applicazione client scrive dati audio nel buffer dell'endpoint e il motore audio gestisce i dettagli del trasporto dei dati dal buffer al dispositivo endpoint.
La casella con etichetta "Driver audio" nel diagramma precedente potrebbe essere una combinazione di componenti driver forniti dal sistema e forniti dal fornitore. Nel caso di una scheda audio in un bus PCI o PCI Express, il sistema fornisce il driver di sistema della classe porta (Portcls.sys), che implementa un set di driver di porta per le varie funzioni audio nella scheda e il fornitore hardware fornisce un driver di adattatore che implementa un set di driver miniport per gestire operazioni specifiche del dispositivo per i driver di porta. Nel caso di un controller audio ad alta definizione e di un codec in un bus PCI o PCI Express, il sistema fornisce il driver dell'adattatore (Hdaudio.sys) e non è necessario alcun driver fornito dal fornitore. Nel caso di una scheda audio su un bus USB, il sistema fornisce il driver di sistema della classe AVStream (Ks.sys) più il driver audio USB (Usbaudio.sys); di nuovo, non è necessario alcun driver fornito dal fornitore.
Per semplicità, il diagramma precedente mostra solo i flussi di rendering. Tuttavia, le API audio principali supportano anche i flussi di acquisizione. In modalità condivisa, diversi client possono condividere il flusso acquisito da un dispositivo hardware audio. In modalità esclusiva, un client ha accesso esclusivo al flusso acquisito dal dispositivo.
Argomenti correlati