[pulseaudio-discuss] VLC, PulseAudio and large tlengths

[Tanu Kaskinen]

On Sat, 2011-08-20 at 20:45 +0300, Rémi Denis-Courmont wrote:
> Sorry... You could maybe argue that an "underrun" is a general situation 
> whereby the buffer is lower than it should because the fill speed is slower 
> than the consumption speed.
> 
> But the libpulse API uses the term "underflow". A buffer underflow is an 
> _empty_ buffer, not merely a less than optimally filled buffer.

Well, when an underflow happens, the stream buffer really is empty. But
there are two buffers: the stream buffer and the sink buffer. As long as
the data that has been previously moved from the stream buffer to the
sink buffer doesn't run out too, glitches are avoidable. Writing to the
stream buffer during an underflow causes the written data to be
immediately moved to the sink buffer, continuing exactly where the
previously written data ended.

> > > > Currently an underrun means that there was not enough data in the
> > > > stream buffer to satisfy the sink's request when it wanted to fill its
> > > > buffer. I'm not saying that the current definition is the best
> > > > possible,
> > > > 
> > > > but I don't see anything obviously
> > > > wrong in it either.
> > > 
> > > Then I'm sorry for you. Go get yourself an English dictionary.
> > > 
> > > > If VLC assumes that an underrun message means silence/glitch, it's a
> > > > bug in VLC,
> > > 
> > > Are you kidding me? Is this that the level of hypocrisy that I should
> > > expect when dealing with PulseAudio?
> > 
> > No, I was not kidding. I didn't think I'd be offensive either, but maybe
> > I came across as rude. Sorry about that. If the term "underrun" causes
> > you to do invalid assumptions about Pulseaudio's internal behavior, then
> > the term may be wrong (which you seem to claim), or the documentation
> > may be lacking.
> 
> The only way that there could be no glitch is if PulseAudio would do some 
> black magic to extrapolate the missing samples, in the event of an 
> "underflow". I don't think this is what happens?

Definetely not. I think I explained above how the gliches are avoided
when underflows happen.

> Anyway. Ignoring underflows is not really an option. When they do _really_ 
> happen, e.g. due to serious scheduling problems, VLC has to resynchronize the 
> stream somehow. I don't see any solution other than down-sampling or padding, 
> or is there?

By resynchronizing I guess you mean maintaining A-V sync? I have never
been in contact with code that implements A-V sync, so I can't speak
very confidently here, but I think the idea is that you can at any time
query the current playback latency (fixed hardware latency + currently
buffered data) and use this information to schedule the video frames. In
case of a "real" underrun, the reported latency stays constant even
though you don't send any audio. In other words, the audio stream time
stops for the duration of the gap in the audio output. Since the audio
time stays stopped, your video frames get delayed accordingly, because
they are scheduled using the audio clock instead of the wall clock.

I'm not sure how downsampling is relevant here. Is the video being
synchronized to the wall clock instead of the audio clock and you need
to make the audio stream go faster to catch up with the video stream? If
that's the case, don't you run into trouble with the wall clock and the
audio clock drifting apart (the sound card most likely doesn't run
exactly at 48000 Hz even if it claims to do so)?

-- 
Tanu