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

[Rémi Denis-Courmont]

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.

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?

> 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.

-- 
Rémi Denis-Courmont