On Sun, 2011-08-21 at 13:41 +0200, David Henningsson wrote: > On 08/20/2011 05:46 PM, Tanu Kaskinen wrote: > > 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. > > Seen from a libpulse user's perspective, I think it would make more > sense to report when there is an underrun in that sense that a glitch is > unavoidable, rather than the current handling. > > That might be a redefinition compared to what PulseAudio currently mean > with underflow/underrun, but I think such a change in definition would > be more useful, and also more in line with what people in general would > expect. What is the reason for the new definition to be more useful? Is it that VLC would like to stop the stream when a glitch happens, throw away some audio from exactly after the point where the glitch happened, and then continue playing from a well-known point? So it's not enough to make the underflow messages happen only when a real glitch happens, the stream must also be automatically corked. What about hw buffer underflows? Currently those are not reported at all, even though I think VLC would like to use the same recovery logic in those cases too. If stopping the stream is required in stream underflow cases to properly handle the glitch, I guess the whole sink needs to be stopped in case of an alsa underflow? Hmmm... no, that should not be required. Only those streams' data needs to be rewound out from the hw buffer that want to use "the better way" of handling underflows. To me the benefits of doing this don't sound very big, but I probably won't oppose if someone wants to implement the needed changes. > > 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. > > There was a problem in that 251 ms of data was not supplied before > stream start, which lead to underrun reports. This was what I suggested > to improve in VLC. > > However, from what I've been told about VLC, the latency (e g with live > streaming) is usually around 500 ms, but can drop down to 40 ms > occasionally, e g with late packet arrival from the network. And I was > hoping that PulseAudio could cope with that, without having to choose a > tlength at 40 ms (or 40 ms * 2, 3 or 4 depending on > PA_STREAM_ADJUST_LATENCY, minreq, etc). My suggestion is to just skip some audio when VLC notices the stream lagging more than what is practical to correct with resampling, and ignore the underflow messages if VLC doesn't want to increase the tlength when underflows happen (maybe it's somehow important that live streams have latency of 500 ms at most). With the current implementation I think the underflow messages are only useful for clients that react to them by increasing the buffer size (and for alsa applications that do stream draining in a silly way). -- Tanu
