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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
