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

[Thomas Guillem]

On Wed, Jul 4, 2018, at 21:03, Rémi Denis-Courmont wrote:
> 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?).

For the example and for simplification, I assumed that the original delay was 0.

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

Yes, maybe I can find a way to do it in a generic way....

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