[vlc-devel] [RFC PATCH 12/13] FIXUP: fix preroll with !pulse aouts

[Rémi Denis-Courmont]

Le tiistaina 3. heinäkuuta 2018, 11.07.45 EEST Thomas Guillem a écrit :
> On Mon, Jul 2, 2018, at 18:02, Rémi Denis-Courmont wrote:
> > I don't perceive a catch-22 at all.
> 
> Irony + novel references make review harder to understand... But thanks
> anyway for this new book in my toread list.

Sorry, I don't understand.

> > If the dejitter delay is accounted by the clock, which it obviously
> > should, then everything should work as things stand.
> 
> Not with the current aout_DecSynchronize() implementation. Sorry If I'm
> not clear enough but the issue is quite hard to explain.What this function
> is doing (without this patch), with the Alsa output (for example):
>  - The first aout->time_get() will return a delay of 0 (works too with
>    an orginal hw delay > 0ms)

ALSA delay is not always 0. This is an artifact of your hardware and driver 
(HDA?).

>  - vlc_clock_Update() will be called with the following argument:
>    (system_now, dec_pts - delay).NB: Since the clock can't handle negative
> values, it should be (system_now + delay, dec_pts) Updating the clock with
> these original values will create a new
> reference point and erase the monotonic (as fallback) reference point
> that is based on the dejitter. Therefore the dejitter is not taken into
> account for next clock update/convert calls.

If I understand you, the problem is that, in PulseAudio case, the output 
always tries to follow the "proposed" date. But in ALSA case, the clock gets 
overwritten by the aout core before the synchronization.

> Maybe the fix should be in clock.c then ? Should the master reference
> point handle this dejitter ? (and not only the monotonic reference)

IIUC, it should be a simple matter of reordering the clock calls by the audio 
output so that the dejitter delay is not clobberred. Assuming that the 
dejitter delay is initially provisioned in the clock by something upstream.

-- 
Rémi Denis-Courmont
http://www.remlab.net/