Perché l'aggiunta di un rendicatore al mio grafico del filtro DirectShow ha appianito l'input audio al grafico?

Question

Ho un grafico a filtro DirectShow nella mia applicazione Delphi 6 costruita con la libreria dei componenti DSPACK. La struttura del grafico è la seguente:

• Filtro audio Push Push Push Source
• Campione grabber
• TEE FILTR (ma solo quando attivo sia lo scrittore di file WAV che il rendering)
• Rendering (dispositivo di output PC preferito)
• WAV File Writer

Il filtro a tee viene aggiunto al grafico solo se ho Entrambi I filtri del rendering e dei file WAV si sono accesi. Altrimenti collego solo il filtro che è acceso direttamente al campione grabber.

L'audio viene consegnato su un server audio RTSP connesso WiFi che è in streaming dell'audio in tempo reale. Se io non Accendi lo scrittore di file WAV, l'audio che esce dalle mie cuffie ha i tipici suoni di pompaggio e clic occasionali associati a un flusso audio non gravoso. Stranamente, non appena accendo il filtro WAV File Writer, l'audio diventa liscio come vetro.

Ho il codice sorgente per lo scrittore di file WAV e fondamentalmente gestisce le attività di produzione dell'intestazione del file WAV corretto quando necessario e di scrivere i buffer audio se necessario, non molto di più. Quindi trovo strano che l'accenderlo sia levigato nel flusso audio in arrivo, soprattutto perché non è a monte del rendering (filtro) ma è invece un filtro tra pari che pende dall'estremità del filtro a tee accanto al rendering.

Qualcuno può dirmi cosa potrebbe succedere per rendere la consegna audio raggruppata quando accendo il filtro dello scrittore file? Il filtro a tee fa un buffering intrinseco? Voglio duplicare lo stesso meccanismo in modo da poter avere un audio regolare quando lo scrittore di file non è acceso. Sto cercando di evitare di aggiungere il mio buffering perché non voglio aggiungere più ritardi al flusso audio in tempo reale di quello che devo.

Answer 1

Se hai una fonte in diretta e puoi ascoltarla e l'audio consegnato allo stesso tempo, potresti essere in grado di dire se l'aggiunta di File Writer introduce un ritardo, che potrebbe essere responsabile della differenza. Oppure potrebbe esserci una variazione di dimensioni o il numero di buffer negoziati in DecideBufferSize.

Suggerirei di introdurre un buffering esplicito nel tuo filtro push, come aggiungere un offset ai stamp di tempo di esempio. Il buffering intrinseco nel filtro TEE potrebbe non essere affidabile. Le variazioni dei tempi di consegna sono inevitabili.

Un approccio più sofisticato, se è necessario eseguire con un buffering minimo o nullo, potrebbe essere quello di allungare/comprimere l'audio preservando il campo.