Re: [LAU] Testing JACK and PA latency

Here's some basic results for those who might be interested in this process.

----------
SETUP
----------

Using this graph:

    jack_delay (out) -> pa_source -> ecasound -> pa_sink ->
system:playback -> analog cable -> system_capture -> jack_delay (in)

Running ecasound with this chain setup:

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

JACK is running with 48k/64/2 in realtime mode.

Gkrellm is running for quick reference to CPU load.

Dual core Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz with 4GB DDR2 667.0 MHz
/ PC2-5300.

Kernel 3.2.0-3-amd64

cat /proc/asound/cards
 0 [Intel ]: HDA-Intel - HDA Intel
                      HDA Intel at 0xd2000000 irq 46

Granted this is not a modern PC system or even a professional grade sound
card but it is similar to modern mobile hardware which is my target
platform.

I see the following results:

With just jack, PA , jack_iodelay running I see CPU pegged at around 30%
on both cores.

With ecasound running but without connecting jack_iodelay to pulse_source
(in), I see CPU Load pegged at between 32% to 55%.

With jack_iodelay connected to pulse_source (in), I see CPU load hovering
around 40% to 65% and generally on the higher side.

----------
RESULTS
----------

- With a clean start from boot and no previous audio apps running at
initialisation of the connection between jack_delay and pa_source

23ms latency

After a second or two things start to go funny. The latency jumps up to
800 ms and then down to 140 ms up again to 480 ms down to 350 ms up to
1067 ms down to 670 ms... In other words it's all over the place.

Granted this is on a consumer grade audio device but a lot of mobile
devices have similar if not exactly the same chipset/driver.

I would like to trace the bottle neck but without running the whole graph
it might not be possible.

Maybe an app that incrementally adds to the signal tone and timestamps
against the summed frequency could be used to trace the location of the
bottle neck?

Suggestions for other things that could be done to minimise the erratic
behaviour are also welcome. Maybe I am missing a crucial tweak to PA for
example?

--
Patrick Shirkey
Boost Hardware Ltd
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user