Resending as the first one appears to have been blocked. On Thu, September 19, 2013 8:46 pm, Fons Adriaensen wrote: > On Thu, Sep 19, 2013 at 08:04:04PM +1000, Patrick Shirkey wrote: > >> > 1. Measure the round-trip latency of your sound card (with an external analog loop). >> > >> >> Can I use jack_delay running on a second computer connected to the external i/o of the first computer to get this value? > > You'd measure something different... > > But you could use two computers as follows: > > A = computer with jack, PA, audacity > B = second computer with sound card, jack and jack_delay. > > 1. Measure the round-trip latency on B, with an external > analog loop. > > 2. Connect B -> A, A -> B, run complete chain on A. > > 3. Measure again on B, subtract the value from (1). > >> > jack_delay -> pa_source -> audacity -> pa_sink -> jack_delay. >> > >> >> Does this look reasonable? >> >> 1023.978 frames 21.333 ms total roundtrip latency >> extra loopback latency: 1023 frames >> use 511 for the backend arguments -I and -O >> 1023.976 frames 21.333 ms total roundtrip latency >> extra loopback latency: 1023 frames >> use 511 for the backend arguments -I and -O >> 1023.977 frames 21.333 ms total roundtrip latency >> extra loopback latency: 1023 frames >> use 511 for the backend arguments -I and -O > > Don't know - I'm by no means a PA expert... and I don't know > your Jack period size. Given PA's reputation I'd expect more: > 1024 samples would mean that PA imposes almost the same RT- > requirements on apps as Jack does, and it was designed *not* > to do that... But maybe the jack <-> PA interface doesn't > use the same amount of buffering that PA normally adds. > > Note that the value measured is modulo 2^16 samples, but I > wouldn't expect anything more than a second, so this probably > irrelevant. > Here's a bit more detail for discussion before I send this over to the PA guys for feedback. I am seeing the time period returned by jack_delay regularly increase during the measurement process. Do you have any thoughts on why that would be happening? I would like to rule out jack_delay because this is most likely a bug in PA that I have come across now. I'm using this method: jack is now set to 64/48000/2 This is the graph: jack_delay -> pa_source -> audacity -> pa_sink -> jack_delay 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 graph and ecachain: 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. Console logs here: http://boosthardware.com/pa-jack-latency.txt > >> > 3. If pa_source and pa_sink are a single Jack client (probably not), >> > subtract one period from the result of (2). >> >> Can you explain that with the data above? > > If they are a single Jack client you create a loop in Jack's > processing graph, this adds one period to the measurement. > > >> > 4. Add the two values. >> > >> >> I would like to provide an app for this task. Do you think it would be worthwhile to extend jack_iodelay for this purpose? > > Don't see how. You need to do two measurements anyway, no matter how it's done, then add or substract. > -- Patrick Shirkey Boost Hardware Ltd _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
