[vlc-devel] [RFC PATCH 12/13] FIXUP: fix preroll with !pulse aouts
thomas at gllm.fr
Thu Jul 5 09:43:24 CEST 2018
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
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
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel