VLC, PulseAudio and large tlengths

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux