Latency Compensation‽

[wolftune]

I tried every program I could, and few seem to have successful latency compensation!
Ardour 2 worked I guess, but I couldn't figure out if it was truly accurate, it seemed a little off.
Otherwise, nothing worked, not Audacity, not Ardour 3, certainly not REAPER under WINE, not QTractor, nothing…
What I did was try a buffer of 2048 so that latency issues would be most noticeable. None of the programs seemed to handle this well.

This is pretty frustrating, because this is an essential requirement to basic audio functioning!

I'm running KXStudio 12.04
And I should note that Ardour doesn't update its (imperfect) latency settings when latency changes elsewhere, only when latency is set internally.

[wolftune]

I wish I were enough of an expert to explain the details, but the essence is that playback and position of recorded items are to be delayed by the same amount as the latency for recording so that when the recorded item is performed to line up with a click or a track being overdubbed, it stays lined up.

I think that it is as simple as doing a feedback test. I think that a prerecorded or computer-generated signal can be played and recorded at the same time and the latency can be measured. It's perfectly reasonable to ask users to go through a simple procedure to undertake this measurement specifically for their setup. Once the latency is determined this way, the program simply needs to automatically adjust the playback position of all newly recorded material by the measured latency.
Ideally, changes to buffer size won't all require new measurements, but can be calculated from the initial measurement. Once the setting for latency compensation is determined, it should work forever on that system.

If I remember right, I did some test like this on my Mac with Digital Performer. It was actually simpler and less precise. It involved, I think, just a paired signal, one that goes straight to playback, and another matched signal that gets routed through to record and then be played back once. I might be fabricating the memory, but maybe there's just a test button to click… And then I just adjusted a compensation slider control until the sounds seemed optimally fused to me. Once set, it was all good from there.

This is all off the top of my head. I'm sure if I searched for more information, I could get better details.

[Capoeira]

to be honest I don't really know how latency compensation is supposed to work...

This is for recording in an oversub situation.
f.e., jack runs with 1ms latency:
a singer records a vocal over an instrumental,
instrumental comes to singers ears 1ms too late,
> singers voice comes to recording app 2ms too late,
latency compensation should now move the recorded track 2ms "to the left"

This is for the software latency.
If one messured the addionional hardware latency, put the value in jack command, and the app reads it and compensates it too, latency compensation theoreticly becomes perfect.

*If st I said is incorrect, feel free to correct


EDIT: started to write this before wolftune's answer....maybe his is more correct

[Pablo]

Ardour doesn't try to compensate hardware latency. As Capoeira points out, you have to enter it manually in jack configuration (setup window). Use jack_iodelay to measure the real round trip latency, including hw latency [1]. OTOH, USB cards are tricky. See [2].

[1] http://linuxmusicians.com/viewtopic.php?f=19&t=8022

[2] http://old.nabble.com/Differences-in-la ... 07033.html

[wolftune]

Thanks, that first link was clear. So I enter stuff in the JACK settings (such as in Cadence) where it says "Extra Latency" and "Input Latency (frames)" and "Output Latency (frames)", right?

But I have to figure out a different number for every setting, whether using internal sound vs USB, and for every buffer size?? Or just for each audio card? I.e. the software isn't set to automatically adjust for buffer size? If not, this should be a top priority!

Ideally, after doing this set up, I could at least save a profile that goes with each audio card, so that it is automatically loaded when I choose that card, and also that it is automatically adjusted for buffer size changes.

I'll try to go through all this with those links, but this is definitely an area where better documentation is needed. It needs to be more clear how to set this. And this needs to be included with the most basic beginners getting-started-with-Linux-audio documentation. Getting this latency correct is of fundamental importance to basic audio work.

[wolftune]

Ok, with my USB interface I got this:

Code: Select all

5248.967 frames    119.024 ms total roundtrip latency
        extra loopback latency: 1152 frames
        use 576 for the backend arguments -I and -O

But the Cadence extra latency boxes only allow up to 99, nothing like 576.
Incidentally, I suppose this whole issue requires that I really know for sure whether or not Cadence is successfully implementing my setting for "Periods/Buffer" (my doubt comes from the fact that Cadence doesn't change its estimate for latency when that setting is changed).

Anyway, I tried the internal sound and got this:

Code: Select all

4151.323 frames     94.134 ms total roundtrip latency
        extra loopback latency: 55 frames
        use 27 for the backend arguments -I and -O Inv

I don't know what "Inv" is, but this number is more manageable. I don't understand why the frames are similar in both cases but the resulting latency in frames is so much more minimal for the internal sound. I read over the link about USB stuff but didn't grasp anything. It was a convoluted back-and-forth discussion, and I don't feel like I know what to do.

On a positive note, it seemed to work in Audacity to simply enter the total roundtrip latency in the preferences (as the negative number for recording offset), although, as I said before, having to change this number every time I switch buffer size or switch between audio devices is really tedious! Of course, with Audacity, the fact that it doesn't do any play-through nor even connect to software means that there's never a reason to change to a low buffer size when using Audacity.

Again, I tried Ardour after entering 27 in both latency boxes in Cadence, using my internal sound. Ardour 2 seemed to handle everything fine. Ardour 3 was still off, particularly when I set the buffer to 2048.

For software where it makes sense to sometimes use different buffer sizes, like Ardour, entering the JACK extra latency stuff ought all that's needed, right? And it ought to otherwise adapt correctly to buffer size changes, right? At least in principle?

And I still have no idea what to do about the USB issue. What do I enter in the JACK settings for that device??

Anyway, thanks for the help. I'd really like to do what I can to help document all this and promote improved tools for this stuff. Being able to accurately overdub is of fundamental importance to almost anyone doing audio. This issue should be considered a very high priority…

[Pablo]

Ok, with my USB interface I got this:

Code: Select all

    5248.967 frames    119.024 ms total roundtrip latency
            extra loopback latency: 1152 frames
            use 576 for the backend arguments -I and -O

But the Cadence extra latency boxes only allow up to 99, nothing like 576.

I normally use qjackctl and this problem doesn't exist. You should tell Falktx about it.

I suppose this whole issue requires that I really know for sure whether or not Cadence is successfully implementing my setting for "Periods/Buffer" (my doubt comes from the fact that Cadence doesn't change its estimate for latency when that setting is changed).

I don't know. Try in a terminal:

jack_bufsize

It should show the current buffer size (frames per period, or "p" for short).

Oh wait, you are talking about periods/buffer ("n" for short). That is a different thing. If I understand it correctly, the theoretical capture latency always equals to p, whereas the theoretical playback latency depends on n and the async / sync mode.

For example, with a PCI card, in sync mode, n=2, p=2048, capture latency would be 2048 and playback latency 2048. Total round trip latency would be 4096. Real latency is 4096 + K1 (to follow the guru's terminology) where K1 is due to hardware, and then you have to put K1/2 in both input and output extra latency boxes.

With a USB card things get more involved. I didn't know this until Luis Garrido told me not long ago. The last email from Luis in that link says:

Round trip latency = p * n + min(p, 24 ms) + K2

I remind: p and n are frames per period and periods per buffer respectively.

min(p, 24ms) means either p or 24 ms, whichever is lower. For example, at a SR of 44100 Hz,

0,024 s * 44100 Hz = 1058 frames

So, with p=2048, n=2, sync mode, 44100 Kz:

roud trip latency = 2048*2 + min(1058, 2048) + K2 = 4096 + 1058 + K2

You can deduce K2 from jack_iodelay results but in this case, the extra latency is (1058 + K2), not just K2.


Note that, in async mode, you will have to add a period size, so these are more general:


PCI cards:

Round trip latency = p * n + p (only if async) + K1

USB cards:

Round trip latency = p * n + p (only if async) + min(p, 24 ms) + K2

K1 and K2 depend basically on the AD/DA converters of the sound card.

Note that jack2 default mode is async. I always run jack2 in sync mode. it works better for me and the latency is more "predictable" and more like it was when I started with jack1 (which doesn't have async mode at all).

I don't know what "Inv" is,

I am not sure either.

but this number is more manageable.

Yes, internal sound card latency is very low in my case as well.

I don't understand why the frames are similar in both cases but the resulting latency in frames is so much more minimal for the internal sound.

See above.

I read over the link about USB stuff but didn't grasp anything. It was a convoluted back-and-forth discussion, and I don't feel like I know what to do.

Clemens is an alsa developer and the guru wrt USB linux audio. We can thank him for our USB devices working at all. Fons wrote jack-delay (jack_iodelay is jack-delay integrated as a jack tool) and he is a DSP expert. Luis is a power user and also linux audio applications developer. It is normal you and me don't undertand all they write but I hope I got it right about the latency and the explanation above sheds a bit of light.

I haven't tested ardour3 yet. I don't use audacity to record either. If you think something is wrong, go forth and report bugs to the upstream developers.

Cheers! Pablo