Le jeudi 19 juillet 2012 11:56:09 David Henningsson, vous avez écrit :
> So how do we solve this? Well, I believe the best fix would be to fix
> PulseAudio to give back underruns later, i e, not until we know for sure
> that the 221 frames have been played back. Right now we send it out when
> the client buffer is emptied, which is too early. Deferring the underrun
> on the PulseAudio side would give the client side a fair chance to fill
> up PulseAudio's big buffer and thus avoid the underrun.
> I remember VLC having some trouble with this behaviour as well.
> This would, however, be some work in PulseAudio to get right. :-/

Previously, VLC would assume an underrun meant a glitch and was thus a good 
opportunity to resync the hard way (that is to say, immediately and without 
resampling). Nowadays, VLC just ignores PulseAudio underruns events, except 
for printing a debug message.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

Reply via email to