[vlc-devel] [RFC PATCH 0/9] Fixing A/V dejitter with high latency devices

Thomas Guillem thomas at gllm.fr
Thu Dec 10 20:10:59 CET 2020

On Thu, Dec 10, 2020, at 20:00, Rémi Denis-Courmont wrote:
> Le jeudi 10 décembre 2020, 19:10:06 EET Thomas Guillem a écrit :
> > The more robust way to fix this issue is to propagate the audio delay
> > from all aout modules asynchronously, not depending on how the input is
> > buffered/decoded.
> That's not the only case. Draining (and probably flushing) should also be 
> asynchronous, so that we can still pause/resume near EOS. Obviously, reporting 
> events as soon as they occur is generally speaking the right thing to do, 
> though I am not familiar with this specific scenario.

Agree for the async drain but I think the issue is less visible for the user than the synchornous time_get() issue. That's why I postponed for 5.0 in my head. 

> However realistically, many HALs won't do asynchronous reporting. And even the 
> PulseAudio daemon is probably just faking it internally, unless ALSA has a 
> mean to do it with the poll API. I don't think that HDA or USB audio or BT 
> audio supports asynchronous latency reports underneath either (I could be 
> wrong there).
> > This patch set implement this solution for Pulse Audio. This module
> > didn't require many modifications to achieve that purpose since the
> > PulseAudio provide a callback to be notified when the latency is
> > updated.
> > 
> > Other modules will be more problematic to fix. I see 2 solutions:
> > 
> > 1/ Writing a threaded time_get helper code. An aout module could use
> > this helper to create a thread that will poll the delay via a time_get
> > callback. During the first phrase, this delay could be fetched every
> > 20ms, and then fetched every 1 seconds once the stream is stabilized.
> How does PA handle ALSA devices?

I didn't check but it is worth checking it for the inspiration.

> > 2/ Add a callback to the master clock that will fetch the aout delay.
> > This callback could be triggered by the vout before displaying a frame.
> That's an interesting out-of-the-box approach but I fear for reentrancy and 
> locking.

I could work on a POC. Such approach will require that the time_get() callback is called from a different thread than other ones. It needs proper documentation and a fix for every aout modules.

> -- 
> Rémi Denis-Courmont
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel

More information about the vlc-devel mailing list