[pulseaudio-discuss] VLC, PulseAudio and large tlengths

[Tanu Kaskinen]

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