[pulseaudio-discuss] Best Case Latency

[Patrick Shirkey]

On Thu, October 3, 2013 12:14 am, Tanu Kaskinen wrote:
> 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.
>

I see the following sprinkled in /var/log/messages

Sep 30 12:19:02 xxx pulseaudio[28845]: [pulseaudio] ratelimit.c: 1997
events suppressed
Sep 30 12:19:02 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally

<snip>

Sep 30 21:40:04 xxx pulseaudio[28845]: [jack-source] ratelimit.c: 41
events suppressed
Sep 30 21:40:04 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Sep 30 21:40:04 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Sep 30 21:40:04 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Sep 30 21:40:04 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Sep 30 21:40:04 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Sep 30 21:40:04 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Sep 30 21:40:04 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Sep 30 21:40:04 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Sep 30 21:40:04 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Sep 30 21:40:04 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Sep 30 21:40:04 xxx pulseaudio[28845]: [jack-source] asyncq.c: q overrun,
queuing locally

<snip>

Oct  1 09:53:30 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Oct  1 10:01:20 xxx pulseaudio[28845]: [pulseaudio] ratelimit.c: 2291
events suppressed
Oct  1 10:01:20 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Oct  1 10:01:20 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Oct  1 10:01:20 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Oct  1 10:01:20 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Oct  1 10:01:20 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Oct  1 10:01:20 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Oct  1 10:01:20 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Oct  1 10:01:20 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Oct  1 10:01:20 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Oct  1 10:01:20 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Oct  1 10:01:20 xxx pulseaudio[28845]: [pulseaudio] asyncq.c: q overrun,
queuing locally
Oct  1 10:01:42 xxx pulseaudio[28845]: [pulseaudio] ratelimit.c: 2321
events suppressed



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

Thanks for that info. What is the 48? Is that 48000/1000 ?




--
Patrick Shirkey
Boost Hardware Ltd