[pulseaudio-discuss] VLC, PulseAudio and large tlengths

[Rémi Denis-Courmont]

Le samedi 20 août 2011 18:46:28 Tanu Kaskinen, vous avez écrit :
> > > VLC currently assumes that a PulseAudio under-run event implies a
> > > silence/glitch. It uses it as an opportunity to resync the audio
> > > stream... this is not good if there was no actual under-run :-/
> > 
> > Agreed. PulseAudio should not send the underrun message if there is a
> > possibility that the client can avoid the underrun by sending more data.
> 
> 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.

Getting fewer samples that you would ideally wish for, but still enough to 
work properly is simply not an underrun.

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

> at least until someone changes the definition that
> Pulseaudio uses.

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