14 May
2009
14 May
'09
11:52 a.m.
On Thu, 14 May 2009 12:02:34 +0200
"Jostein Chr. Andersen" <jostein(a)vait.se> wrote:
I', really sorry about the noise, but think I did
it right this time:
On Wednesday 13 May 2009 23.06.05 hollunder(a)gmx.at wrote:
...
Yep, that's the way to do it.
I did it wrong at first as well..
The question is if this is a calculated or real (measured) value.
Consider measuring with jdelay.
I physically connected a patch cable between the 1010's channel 3 out
an in and then in qjackctrl connected jack_delay's out to system
playback_3 and system capture_3 to jack_delay's in. Now, the picture
changed totally: With latencies 2.9 according to qjackctl:
capture latency = 64
playback_latency = 128
262.197 frames 5.946 ms
262.190 frames 5.945 ms
262.190 frames 5.945 ms
262.190 frames 5.945 ms
262.191 frames 5.945 ms
and with latency 0.726 according to qjackctl:
capture latency = 16
playback_latency = 32
117.187 frames 2.657 ms
117.190 frames 2.657 ms
117.191 frames 2.657 ms
117.191 frames 2.657 ms
117.191 frames 2.657 ms
These values look good to me, just remember that the nicest values
won't help you unless you can get them under heavy load without xruns.
Expect worse numbers from your usb device. I have some measurements
from mine and some other people were so kind to provide some as well,
just need to put them together for a comparison some day.
But this just mean that latency because the soundcard
is at the best
2.7 ms when sending sound from it's out to it's in and it is better
when just recording, right?
Yes, this is round-trip latency, just in or just out will be faster
(take half(?) the time).
And apps that is jack only connected
still have 0.4 ms latency?
From which measurement do you conclude that?
Jack itself shouldn't really add latency afaik but I'm no expert.
Thanks for pointing me to jack_delay.
Jostein
You're welcome, it's a really handy tool (if you are interested in
real, not just low, numbers).
Regards,
Philipp