On Sat, September 21, 2013 5:08 am, Fons Adriaensen wrote:
Are there competing definitions these days?
>> I'm running jack with realtime capabilities but not a realtime kernel.
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
> Try to record the signal coming back from the PA-sink, e.g. using
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?
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
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?
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.
Boost Hardware Ltd
Linux-audio-user mailing list