[pulseaudio-discuss] VLC, PulseAudio and large tlengths

[Rémi Denis-Courmont]

Le samedi 20 août 2011 20:20:27 Tanu Kaskinen, vous avez écrit :
> > > Why not? It sounds like you'd want to define "underrun" differently
> > > from what it's currently defined as.
> > 
> > An audio underrun is a situation whereby the next sample is not available
> > by the time that it is needed. That is the One And Only definition.
> 
> To me it seems like your definition is compatible with my definition. An
> underrun message is sent when there's no audio in the stream buffer when
> it's needed by the sink. There just happens to be period of time after
> the underrun when a glitch can still be avoided by rewriting the sink
> buffer.

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.

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

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?

Now, if we assume there was an "underflow", I think it's sane to assume that 
there will be a glitch. One glitch sounds bad, but it sounds better (IMHO) 
than both a glitch and then temporary downsampling... That's the rationale.

It's also a lot less CPU intensive to not resample.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis