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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
