[LAU] Testing JACK and PA latency

Patrick Shirkey pshirkey at boosthardware.com
Sat Sep 21 11:26:58 UTC 2013


On Sat, September 21, 2013 5:08 am, Fons Adriaensen wrote:
> On Sat, Sep 21, 2013 at 04:07:32AM +1000, Patrick Shirkey wrote:
>
>> I can hear the signal fine but I cannot hear or see the result of the
>> signal after it comes back in the mic input. I could attempt to capture
>> that part of the signal too for reference sake.
>>
>> If there are significant dropouts will that be the likely cause of the
>> "??"
>
> Depends on what you mean by 'dropouts' :-)
>

Are there competing definitions these days?

>> I'm running jack with realtime capabilities but not a realtime kernel.
>
> That should be fine. I haven't used a RT-patched kernel for years.
>
> The loop via system:playback -> cable -> system:capture is only
> there to give you the real round-trip latency, it doesn't have
> any importance for examining this problem. You could just send
> the signal from PA-sink directly to jack_delay.
>

In this case PA is not in the loop. However I am running the system at 64
frames/period and it is an onboard hda_intel chipset so I am not expecting
miracles.

> Try to record the signal coming back from the PA-sink, e.g. using
> timemachine. I'm pretty sure there will be discontinuities in the
> recorded waveform.
>

I can hear the signal coming out of the speakers. I can't hear or see it
easily once it has been returned into the system again via the mic. My
ears could be deceiving me though.

Does anyone have another suggestion for how to accurately monitor audio
discontinuities in realtime so I can rule them out or tweak the system
until they are no longer occurring?

zita-scope perhaps?

Regarding scripting the test procedure. Basically start up jack at varying
period sizes and run the test system for x amount of time (minimum of 10
mins). Collate the details returned by the console logs and parse them
into a report.

Number of nodes in the graph
Average latency
Number of xruns
Number of changes to the latency
Total number of x latency recorded
Number of xruns during x latency
CPU load during x latency
Processes running during x latency and CPU load for each process

What I am missing from the report is latency between each node in the
graph. I think jack_iodelay could be extended to provide a passthrough for
an input signal pulse and send a response at another frequency using the
input pulse as a trigger then timestamp the signals and report the
individual latencies. Maybe this could be done with a single instance so
that they all share the same clock and logging mechanism?

ex.

jack_delay --ports=4

The graph would then look like  this:

jack_delay (out1) -> pa_source (in) -> jack_delay(in2) -> jack_delay
(out2) -> ecasound (in) -> ecasound (out) -> jack_delay (in3) ->
jack_delay (out3) -> pa_sink (out) -> jack_delay (in4) -> jack_delay
(out4) -> system_out -> system_in -> jack_delay (in1)

Obviously sharing a port of jack_delay between JACK and PA is going to be
a mother trucker to implement and is probably the most painful method, so
if there are other more effective and simpler methods to get the data out
of the system it would be very helpful to know about them.



--
Patrick Shirkey
Boost Hardware Ltd


More information about the Linux-audio-user mailing list