[pulseaudio-discuss] VLC, PulseAudio and large tlengths

[David Henningsson]

On 08/20/2011 05:46 PM, Tanu Kaskinen wrote:
> 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.

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.

(Just to complicate things further, add to the equation that some sink 
types do not support rewinding. But in such cases I think the proposed 
definition is actually equivalent to the current definition.)

> 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).

> 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?).

Yeah, usually minreq is low enough to be insignificant.

> 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.

Or - seen from the other side - it would be a bug, or at least lack of 
feature, in PulseAudio, to not have underrun reporting in a way that's 
useful to VLC. Anyway, that's not really relevant to me - for me finding 
a scapegoat is not the point here, the point is that we both want happy 
end users to enjoy all nice features of VLC and PulseAudio together, 
without having glitches or other problems with their audio :-)

> 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.

Yes, A/V synchronisation (in combination with not having the audio clock 
as master clock) is what requires the stream to start at a specific 
point in time.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic