[vlc-devel] [PATCH] RFC: clock/aout: audio preroll discussion

Rémi Denis-Courmont remi at remlab.net
Tue Jun 19 21:38:58 CEST 2018


Le tiistaina 19. kesäkuuta 2018, 21.35.05 EEST Denis Charmet a écrit :
> > Err no. Start() does not have any audio data. Most audio outputs start
> > on the
> > first Play(). And that first Play() actually conveys zero padding
> > generated by
> > the core to time the playback correctly.
> > 
> > The problem is that this does not generally work well. It requires
> > that the
> > latency is known correctly up-front. Not all audio drivers/hardware
> > can
> > support this.
> 
> Couldn't we separate the feeding of the buffer from it's playback state
> (in the limits of the buffer)?

Some plugins would probably be unable to implement such an interface.

> Is it what corking does?

Yes.

> If not could you explain it? I don't know
> really know how pulseaudio works...
> 
> Just to be sure the date field of Play is the date when the audio frame
> passed as parameter should be played?

Yes. It substitutes block->i_pts, as that will soon contain the original PTS 
instead of the intended playback time.

> <thinking out loud>
> If so, if the time_get is inaccurate it could cause the buffer to
> underrun. Could we theoretically use that to somehow correct the TimeGet
> errors?
> </thinking out loud>

I don't understand.

> > This is exactly what is already being done if TimeGet() succeeds
> > before playback starts.
> 
> I agree that if TimeGet is accurate it should work since the delay is
> applied before calling clock_update.
> 
> But I need to retry because some of my early tests using alsa showed
> crazy values which kinda spawned my concerns about timing the aout play
> thread. But I've made so many changes that it might end-up better than I
> expected.
> 
> >>  2/ Modify the aout API to handle 2 type of aout modules: one like
> >> 
> >> pulseaudio (that handle a play date), and all the others one.
> > 
> > And this is the only way to get things working somewhat properly
> > within the current system, where the playback time is determined ahead.
> 
> Just to be sure, can you confirm that the playback time is determined
> ahead so we can start playing the audio after the dejitter delay or are
> there any more complex reasons?

I do not know why the playback time is determined ahead, other than that the 
VLC design has always been that way.

A plain dumb audio player will start audio playback *without* a defined time, 
and determine the actual play time from the audio clock. This avoids the 
problem of inaccurate initial delay, and allows arbitrarily slow audio outputs 
(AirPlay...). But it creates a whole lot of other problems.

> > I prefer solution 2 and the proper API is what we have right now.
> 
> So no "timing" notifications that we could use to call clock_update?

I don't understand.

> Could we somehow write a generic corking wrapper which could be used in
> less evolved aout or is it too specific?

I don't know.

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





More information about the vlc-devel mailing list