On 08/19/2011 10:34 PM, R?mi Denis-Courmont wrote: > Hello, > > Le vendredi 19 ao?t 2011 21:02:59 David Henningsson, vous avez ?crit : >> I've spent most the afternoon trying to figure out why VLC doesn't work >> well with a large tlengths. I seem to have found suboptimal behaviour on >> both the PulseAudio and VLC sides. > > Nice. > >> What bothers me on the PulseAudio side is this call (in alsa-sink.c, >> mmap_write): >> >> pa_sink_render_into_full(u->sink,&chunk); >> >> For this example, assume tlength is 500 ms and minreq is 50 ms. In >> adjust latency mode (which I understand is recommended for power >> efficiency), this is configured to the client's tlength/2 - minreq = 200 >> ms. The problem here is that if the client is filled up to only e g 130 >> ms, PulseAudio will take the 130 ms, the client will underrun, and hand >> out 70 ms of silence. A better behaviour would be to write the 130 ms >> that are available, and go to sleep until the 130 ms is almost up and >> see if more data has come in at that time. >> >> However, things are probably not as bad as it looks. If a new package >> comes in from the client in time, I believe PulseAudio would rewind back >> the 70 ms of silence and write the new data, and no glitch will be >> heard. So the worst thing is actually the somewhat "false alarm" sent to >> the client. > > 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. Fixing that is quite complex though. :-( >> However messing with PulseAudio's buffering mechanisms isn't giving me >> warm and fuzzy feelings, at least not right before the 1.0 release :-D >> >> So over to the VLC side. I started off with the current git head of VLC. >> >> For the synchronisation, I believe the correct way is to do something like: >> 1) when the first packet arrives, notice its timestamp (pts), and set a >> system timer to trigger at that point in time (i e trigger in i->pts - >> mdate() usecs) > > Yeah. That would certainly be better than the current zero padding of the > stream, especially when resuming from pause (i.e. PulseAudio uncorking). > > But but, VLC does not have a mainloop. A timer is going to need a dedicated > thread. Or maybe libpulse can accept user timers in its threaded mainloop? Yes you can, use the pa_threaded_mainloop_get_api(vlc_pa_mainloop)->time_new() [1] function to start a timer. >> 2) the callback from the system timer would then uncork/trigger the stream. >> At that point, PulseAudio's buffer has been filled up by all the other >> calls to Play that happened in between. >> >> I did a quick hack myself: I didn't know how to do system timers in VLC >> so I set it to check at every call to Play, if it was yet time to start >> the stream. (And commented out the call to stream_resync.) That gave >> good synchronisation as well as I could see (being layman on observing >> synchronisation issues). > > vlc_timer_*() functions. But I'd rather use the Pulse mainloop if possible. > >> For the buffering attributes, I tried setting tlength to 500 ms (note: >> AOUT_MAX_PREPARE_TIME is actually 2000 ms, not 500 ms as I originally >> thought). >> Given an initial filled buffer as suggested above, that did not >> underrun. That was with playing back a local video file. >> I set minreq to AOUT_MIN_PREPARE_TIME (40 ms), which is mostly taken out >> of the air. >> >> However, given the reasoning above, if you want to be certain to avoid >> the false underrun alarms as outlined in the PulseAudio section, I >> believe a minreq of AOUT_MIN_PREPARE_TIME and tlength of >> AOUT_MIN_PREPARE_TIME * 4 = 160 ms should be a relatively safe setting. > > In my experience, larger tlength caused more underruns. But maybe that's > because VLC is more likely to be continuously late? I think this is mostly because the "false alarm" problem on the PulseAudio side. However, the problem is not linear, and the boundary for where this starts to happen should be when tlength = AOUT_MIN_PREPARE_TIME * 4 if minreq = AOUT_MIN_PREPARE_TIME. >> Also remember to set the PA_STREAM_ADJUST_LATENCY flag. > > It's not clear to me what this actually will do. Without knowing all the details myself, there are differences in how the buffering is done. The calculations above are based on setting the PA_STREAM_ADJUST_LATENCY flag, which is also what most other applications do these days. If the flag is not set things are calculated differently - the hw stuff is done in larger chunks, which means more false underruns (or rather, the boundary for when this starts to happen is lower), and I *think* (not sure) that you're also more likely to be affected by other streams (i e buffering behaviour changes when other streams are played in parallel to yours). >> Hopefully this gives a little insight in the current problems with VLC >> and PulseAudio! > > -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic [1] http://www.freedesktop.org/software/pulseaudio/doxygen/structpa__mainloop__api.html
