[vlc-devel] [RFC PATCH 0/9] Fixing A/V dejitter with high latency devices
remi at remlab.net
Thu Dec 10 20:00:30 CET 2020
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
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.
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
> 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
> 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?
> 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
More information about the vlc-devel