Latenza di flusso durante la registrazione
Mentre un flusso di record audio si trova nello stato Run, il ruolo del driver di porta WaveRT è minimo. Come illustrato nel diagramma seguente, durante il processo di registrazione, il dispositivo audio acquisisce i dati audio e lo scrive nel buffer ciclico. Il motore audio legge quindi questi dati dal buffer. Questa attività non richiede alcun intervento dal driver della porta. In altre parole, i dati audio vengono scorrere direttamente tra l'hardware audio e l'applicazione in modalità utente senza essere toccati da eventuali componenti software in modalità kernel.
Nel diagramma seguente, il record e le posizioni di lettura vengono continuamente progressi da sinistra a destra quando il flusso scorre attraverso il buffer. Quando il record o la posizione di lettura raggiunge la fine del buffer, viene eseguito il wrapping all'inizio del buffer.
Il diagramma precedente identifica la posizione record come posizione del buffer dell'esempio che il dispositivo audio sta attualmente registrando (acquisizione dal microfono tramite il convertitore analogico-digitale o ADC). Si noti che la posizione del record è la posizione del buffer futuro in cui il dispositivo audio scrive l'esempio dopo che passa attraverso FIFO. La posizione di lettura è la posizione del buffer da cui il motore audio legge l'esempio successivo.
La latenza dal momento in cui il dispositivo audio acquisisce un esempio audio in ADC fino a quando il client legge semplicemente la separazione tra il record e le posizioni di lettura. Questa separazione è la somma delle origini di latenza seguenti (contrassegnate come A e B nel diagramma):
Latenza A: dopo l'acquisizione di dati da ADC, il dispositivo audio archivia i dati in un FIFO hardware finché non può scrivere i dati nel buffer ciclico.
Latenza B: dopo che il dispositivo audio scrive i dati nel buffer ciclico, i dati si trovano nel buffer finché il client legge i dati.
Il client non ha alcun controllo sulla latenza A, che dipende interamente dall'hardware. Un fiFO tipico potrebbe archiviare circa 64 esempi da ADC. Tuttavia, il client controlla la latenza B. Rendere troppo grande la latenza introduce ritardi non necessari nel sistema, ma rendendo troppo piccoli i rischi di lettura dei dati troppo presto, prima che il dispositivo audio sia stato scritto nel buffer.
Anche se il client può configurare un timer per attivare periodicamente il thread di lettura del buffer, questo metodo non ottiene la latenza più piccola. Per ridurre ulteriormente la latenza, il client può configurare il dispositivo audio per generare una notifica hardware ogni volta che il dispositivo termina la scrittura di un nuovo blocco di dati di acquisizione nel buffer. In questo caso, il thread client viene attivato dalle notifiche hardware anziché da un timer.
Se il dispositivo audio invia periodicamente una notifica al motore audio, il client può rendere la latenza più piccola di quanto altrimenti sarebbe pratica.
Il client (in genere il motore audio) può ottenere un riepilogo dei ritardi che il dispositivo audio contribuisce a trasmettere la latenza inviando una richiesta di KSPROPERTY_RTAUDIO_HWLATENCY al driver della porta WaveRT.
Dopo che il client determina la quantità di separazione da mantenere tra il record e le posizioni di lettura, il client monitora le modifiche nella posizione del record per determinare la quantità di ritardo della posizione di lettura. In Windows Server 2008 e versioni successive, il client invia un KSPROPERTY_AUDIO_POSITION o una richiesta di proprietà KSPROPERTY_RTAUDIO_POSITIONREGISTER per determinare la posizione del record. Quest'ultimo metodo di richiesta è più efficiente perché consente al client di leggere la posizione del record direttamente senza la transizione a una routine in modalità kernel per le informazioni.