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
