[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