Considerazioni sull'implementazione del routing di flusso
In Windows 7, le API della piattaforma di alto livello che usano LE API audio principali, ad esempio Media Foundation, DirectSound e Wave, implementano la funzionalità di routing del flusso gestendo il passaggio di flusso da un dispositivo esistente a un nuovo endpoint audio predefinito. Le applicazioni multimediali che usano queste API usano il comportamento di routing del flusso senza alcuna modifica all'origine. I client WASAPI diretti possono usare le notifiche inviate dai componenti Audio core e implementare la funzionalità di routing del flusso.
I client WASAPI diretti (applicazioni multimediali che usano direttamente WASAPI) ricevono nuove notifiche di sessione audio e dispositivo inviate dai componenti Core Audio. Il comportamento della funzionalità di routing del flusso è definito dal modo in cui l'applicazione gestisce queste notifiche.
L'API MMDevice e la sessione audio inviano notifiche sulle modifiche dello stato del dispositivo e sulle modifiche della sessione ai client WASAPI sotto forma di callback. Per ottenere queste notifiche, il client deve registrare l'implementazione di IMMNotificationClient e IAudioSessionEvents. Per altre informazioni, vedere Notifiche pertinenti per il routing di flusso.
Nello scenario del visore VR USB descritto in Routing di flusso, un'applicazione sta riproducendo un flusso audio e usa MMDeviceAPI e WASAPI per eseguire il rendering del flusso nel dispositivo di rendering predefinito Speaker. Quando il dispositivo predefinito viene modificato, l'applicazione riceve una notifica IMMNotificationClient. L'applicazione riceve anche notifiche IAudioSessionEvents che indicano che l'utente ha rimosso il dispositivo endpoint audio o che il formato del flusso è stato modificato per il dispositivo a cui è connessa la sessione audio. Dopo aver ricevuto le notifiche, l'applicazione interrompe lo streaming all'endpoint dell'altoparlante e riapre il flusso per il rendering sull'endpoint predefinito corrente, il visore VR.
In risposta a tali notifiche, il client potrebbe riaprire il flusso nel nuovo dispositivo predefinito nel nuovo formato selezionato dall'utente.
Gestione dei flussi
L'elenco seguente riepiloga i passaggi che un client WASAPI deve eseguire per fornire la funzionalità di cambio del flusso.
Attendere la notifica IMMNotificationClient pertinente. Se il dispositivo è il dispositivo predefinito, viene ricevuta la notifica IMMNotificationClient::OnDefaultDeviceChanged.
Se è disponibile un nuovo dispositivo, ottenere un riferimento all'endpoint del nuovo dispositivo. Chiama IMMDeviceEnumerator::GetDefaultAudioEndpoint per il nuovo dispositivo predefinito. Se il nuovo dispositivo non è il dispositivo predefinito, è possibile recuperare il dispositivo chiamando IMMDeviceEnumerator::GetDevice. Per altre informazioni, vedere Recupero dell'endpoint del dispositivo per il routing di flusso.
Attendere IAudioSessionEvents ::OnSessionDisconnected con il valore reason.
Nota
Poiché tutte queste operazioni sono asincrone, non è possibile prevedere l'ordine in cui l'applicazione riceve notifiche di modifica del dispositivo e disconnessione della sessione. L'applicazione deve implementare la gestione delle notifiche per ricevere queste notifiche in qualsiasi ordine. Tuttavia, in genere, l'applicazione riceve il valore AudioSessionDisconnect prima della notifica di modifica predefinita del dispositivo.
Valutare il valore del motivo e determinare se il flusso deve essere trasferito a un altro endpoint audio o se il flusso deve essere reinizializzato con un nuovo formato.
Arrestare lo streaming nel dispositivo predefinito precedente se il motivo indica che il flusso deve essere reinstradato al nuovo dispositivo predefinito.
Eseguire calcoli di mapping delle posizioni.
Aprire il flusso nel nuovo dispositivo e trasferire tutte le informazioni sullo stato.
Riprendere lo streaming nel nuovo dispositivo predefinito.
Gestire la partenza del dispositivo predefinito precedente.
Per rendere l'operazione di commutazione del flusso senza problemi, è necessario eseguirla il più rapidamente possibile. Ciò dipende dalle prestazioni dei componenti coinvolti nella riesezione del flusso nel nuovo dispositivo.
Considerazioni sul mapping delle posizioni
Quando l'applicazione ottiene le notifiche IMMNotificationClient e IAudioSessionEvents, può instradare i flussi esistenti al nuovo dispositivo predefinito. Quando un flusso audio esistente viene interrotto e aperto nel nuovo dispositivo, il rendering sul nuovo dispositivo deve iniziare nella posizione in cui il flusso è stato arrestato nel dispositivo precedente. A tale scopo, l'applicazione deve avere l'ultima posizione nota del dispositivo per calcolare la posizione iniziale nel nuovo dispositivo. Ad esempio, questa posizione può essere usata come offset differenziale per il mapping di posizione successivo. Quando il flusso avvia il rendering, la nuova posizione del dispositivo può essere mappata alla posizione del dispositivo memorizzata nella cache.
I passaggi seguenti riepilogano il processo di transizione senza problemi di flusso.
- Memorizzare nella cache l'ultima posizione del dispositivo nel dispositivo precedente.
- Arrestare il flusso nel dispositivo precedente.
- Eseguire il mapping dei calcoli per ottenere la nuova posizione.
- Avviare il rendering del flusso nel nuovo dispositivo.
- Rilasciare il flusso precedente.
Durante la transizione, l'applicazione deve assicurarsi che l'orologio non venga sincronizzato, generando flussi audio e video non sincronizzati. Questo problema può verificarsi se i campioni video continuano a eseguire il rendering mentre il flusso audio viene instradato al nuovo dispositivo. L'applicazione deve memorizzare nella cache la posizione dell'orologio per il calcolo del mapping e assicurarsi che il rendering degli esempi video non venga eseguito fino a quando il flusso audio non viene riaperto nel nuovo dispositivo, in modo che quando il clip riprende il rendering, l'audio e i flussi video vengono sincronizzati. In alcuni casi, in cui il tempo di presentazione per il rendering dei fotogrammi video è basato sull'orologio audio, è sufficiente arrestare il flusso audio fino al completamento del cambio di flusso e non è necessaria un'altra implementazione del mapping di posizione per il flusso video per la sincronizzazione video.
Se durante il rendering, IAudioRenderClient::GetBuffer restituisce un errore perché il dispositivo precedente viene perso, l'applicazione non deve arrestare il flusso precedente perché l'operazione di streaming è già stata terminata. Per informazioni sulla gestione di questo errore, vedere Ripristino da un errore di dispositivo non valido.
Argomenti correlati