On Sat, 2011-08-20 at 09:33 +0200, David Henningsson wrote: > 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. Why not? It sounds like you'd want to define "underrun" differently from what it's currently defined as. 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. If your explanation of the sink latency calculation is correct, then it sounds like underruns with a reasonably high tlength (like 500 ms) and reasonably low minreq (like 50 ms) should be rare. If VLC is having constant underruns, that sounds like a problem at VLC's end. The sink will never request more than 200 ms at a time. The worst case is if the stream buffer contains 451 ms worth of audio (no request sent to VLC yet), and the sink asks for the full 200 ms amount. After that the buffer will contain 251 ms, and VLC will get a request to send 249 ms worth of audio. VLC will at the very least have 251 ms margin to send the data. That doesn't sound like a difficult target to achieve. If VLC would support higher tlengths than 500 ms, it would be even easier to avoid underruns. I would guess that the the minimum margin of 251 ms isn't a coincidence - the reaction time given to clients is probably never less than tlength / 2 (so maybe minreq doesn't even play a significant role in avoiding underruns?). If VLC assumes that an underrun message means silence/glitch, it's a bug in VLC, at least until someone changes the definition that Pulseaudio uses. Also it sounds like making things more complicated than necessary if VLC doesn't use Pulseaudio's prebuffering feature, but corks manually the stream during prebuffering. But maybe there are valid reasons for that. -- Tanu
