I have seen this topic discussed previously, but did not find “the answer” so I’ll ask again, and promise to document the solution when I get one. With an analog loop setup (ardour - jack - RMERaydat - ADAT - D/A - A/D - ADAT - Raydat - jack - Ardour) I have about 10ms of uncompensated latency. [so if I play a previously recorded click track out one channel, and loop it back into another channel and record it, the recorded channel is delayed by about 10ms]. If I double the jack Frames/Period, this latency also doubles. I would bet the solution lies with a Jack setting, but alas I have not found it. Thanks all…
Setup:
Ubuntu Studio 11.04
Updated to 2.6.39.4
Jackmp 1.9.7 rt via QjackClt
Ardour 3.a10
Just after my initial post I found a post by Paul in 2009 discussing Jack and -I and -O switches. I have tried those with no result…
I have also tried putting jackd into synchronous mode (adding -S to the server path in Qjackctl like so: /usr/bin/jackd -S) This does affect the total latency I measure, and reduces it roughly 1/3 as I would expect. No values for either Input or Output Latency entered into Qjackctl (for either synchronous or asynchronous) mode have any effect on the track to track latency. (I can see they are being passed properly in the message window).
I went ahead and tested the same configuration with Ardour 2.8.11. I had a skew as before, converted that time into frames, stuck that value into Qjackctl as input latency and Presto! Perfect alignment of the playback and recorded track. SO, either there is a default setting with 3.a10 that causes it to ignore the parameters that should come from jack 2) There’s something else that I don’t have set correctly in 3.a10 that needs to be set, or 3) there is a bug in 3.a10. This isn’t the place to report bugs… I’ll do that correctly. However, before I do, I want to make fairly sure it is a bug. Any comments or thoughts on this… anyone… anyone…
lhm: if 2.8.11 gets this right with JACK 1.9.7 its purely by accident, since 2.8.11 uses the old JACK latency API which was replaced (though not removed) in that version of JACK. 2.8.12 will use the new API (like 3.0) and will get this right. When I’ve tested 3.0, it appeared to me get it right, but testing this stuff is way, way more complex than I suspect you’ve encountered so far (there are theoretically at least 64 possible test cases that need to be checked), and some of the work i’ve done getting 2.8.12 to use the new JACK latency API has given me a few doubts about the situation in 3.0.
Think I understand from your comments that I am dealing with a known, or at least suspected, issue. What ever 2.8.11 is doing it did it correctly for me… Understand that’s not necessarily the way to do it going forward, and I obviously defer to you and the other developers to address that. I’ll go ahead and file a bug report for tracking and the benefit of others. If there is a uniqueness to the hardware that I have (RME HDSPe Raydat) I’ll be glad to test/evaluate any code you drum up. Otherwise, I’ll stand by and look for some indication of resolution. Regards