19 Sep
2013
19 Sep
'13
2:32 p.m.
Resending as the first one appears to have been blocked.
On Thu, September 19, 2013 8:46 pm, Fons Adriaensen wrote:
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?
--
Patrick Shirkey
Boost Hardware Ltd
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).
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).
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
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 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?
Don't see how. You need to do two measurements anyway, no matter how
it's
done, then add or substract.