[pulseaudio-discuss] Best Case Latency

[Tanu Kaskinen]

On Tue, 2013-10-01 at 00:38 +1000, Patrick Shirkey wrote:
> On Sat, September 28, 2013 3:12 am, Patrick Shirkey wrote:
> >
> >> On Sat, September 28, 2013 12:53 am, Tanu Kaskinen wrote:
> >> I don't remember if the alsa compatibility layer forwards the
> >> stream under/overrun notifications to the alsa application - IIRC there
> >> were problems when those were reported and there were different
> >> problems
> >> when those were not reported, and I don't remember what the current
> >> code
> >> does.
> >>
> 
> This seems like it would be a good place to verify.

Looking at the pulse alsa plugin source, it seems that stream overflow
events (the recording direction) are not reported. Underflows (the
playback direction) are reported by default (configurable in asoundrc).
Overflows are pretty unlikely, since the maximum stream buffer length
appears to be configured to 4 MB.

> Do you have any
> suggestions for how to test/measure the code/buffer at this point in the
> graph?

snd_pcm_delay() returns what pulseaudio thinks is the latency. That is,
the pulse plugin basically just calls pa_stream_get_latency(). It seems
that the plugin doesn't do any buffering of its own, so there shouldn't
be any need to worry about the alsa plugin layer adding latency.

> Also does anyone know why the PA Stream Buffer is hovering around 10ms?
> That number doesn't appear to match the 64 frames/period that JACK is set
> to so it would be useful to verify that it is calculated correctly and/or
> if it can be lowered.

You can see in the pulseaudio log, when a stream is created, what
memblockq parameters the client requests and what are the final
parameters.

According to pcm_pulse.c, the requested stream buffer length (tlength in
the memblockq parameters) should be

    io->buffer_size * pcm->frame_size;

I don't know how io->buffer_size is calculated, but I'd expect that to
be based on the period number and size provided by you (number of
periods * period size).

2 (periods) * 64 (frames per period) * 4 (bytes per frame) / 48
(frames/millisecond) equals 10.67 milliseconds, so it looks like the
reported latency of 10 milliseconds for playback is what you'd expect.

-- 
Tanu