[pulseaudio-discuss] Best Case Latency

[Patrick Shirkey]

On Thu, September 19, 2013 6:52 pm, Patrick Shirkey wrote:
>
> On Thu, September 19, 2013 6:42 pm, Tanu Kaskinen wrote:
>> On Wed, 2013-09-18 at 04:28 +1000, Patrick Shirkey wrote:
>>> Hi,
>>> Can someone shed some light on the best case and typical latency that
Pulse provides for standard operations?
>> What do you mean by standard operations? I'd estimate volume changes
etc. normally (on an ALSA sink) have a few millisecond latency (best
case 0.5 ms audio buffer + scheduling latency).
>
> Just a "normal" round trip signal flow, for example : PA (in) ->
audacity
> (in) -> audacity (out) -> pa (out)
>
>
>>> Also how that is affected by using jack-sink assuming jack is set to the
>>> lowest possible latency that a device can handle?
>> When jackd asks for N frames from PulseAudio, pulseaudio will render N
frames. There's no extra buffering done in the Jack sink, so volume
changes etc. will have latency that is roughly the same as the normal
Jack client latency.
>
> Do you have an suggestions on how to get an accurate measurement?
>


I'm using this method:

  jack_delay -> pa_source -> audacity -> pa_sink -> jack_delay

jack is set to 64/48000/2

Using audacity with 0 internal latency and in pass through mode I see the
following results. It starts out as 10.667ms and after a few seconds it
climbs up to 70.667 ms.

I see similar results with ecasound instead of audacity using the
following chain:

jack_delay -> pa_source -> ecasound -> pa_sink -> jack_delay

ecasound -f:32,2,48000 -b:64 -i alsa -o alsa

In that case it starts at 60.000 ms and climbs upto 572.000 ms after a few
seconds of running the test.

Full console logs here:

http://boosthardware.com/pa-jack-latency.txt

This appears to be caused by PA adding more buffer on a regular basis. Any
thoughts on why this is happening and how to stop it?



--
Patrick Shirkey
Boost Hardware Ltd