JACK - latency compensation not staying the same

Optimize your system for ultimate performance.

Moderators: MattKingUSA, khz

Post Reply
Matt73
Established Member
Posts: 57
Joined: Fri Aug 27, 2021 5:07 am
Has thanked: 8 times
Been thanked: 6 times

JACK - latency compensation not staying the same

Post by Matt73 »

Hello Good People,

I am using Ubuntu Studio (the latest Jammy Jellyfish version) and JACK to record music in my DAW. The DAW is Tracktion and sees JACK fine. So I start up JACK from with Studio Controls when I want to start recording. Then I open the DAW and usually do a latency detection test (looping the signal) within the DAW. Although it was right during the previous session. I have to redo the detection test every time I open the DAW otherwise the overdubs are out of line. I don't doing this but the latency compensation changes during the recording session. I set it right within the DAW and test it and its good but then after a few takes I go back and test it again and it's off. I wonder why it changes like this. I have to restart JACK and then do the detection again and then run the test loop again and it's good for a bit but then changes again. It makes it so that I am never sure if the guitar tracks are lining up right.

Any advice appreciated as always.

Best

Matt

User avatar
LAM
Established Member
Posts: 992
Joined: Thu Oct 08, 2020 3:16 pm
Has thanked: 140 times
Been thanked: 348 times

Re: JACK - latency compensation not staying the same

Post by LAM »

From: https://manual.ardour.org/synchronization/latency-and-latency-compensation/

On Linux, the latency of USB audio interfaces is not constant. It may change when the interface is reconnected, on reboot and even when xruns occur. This is due the buffer handling in the Linux USB stack. As a workaround, it is possible to recalibrate the latency at the start of each session and each time an xrun occurs.

in mix, nobody can hear your screen

Matt73
Established Member
Posts: 57
Joined: Fri Aug 27, 2021 5:07 am
Has thanked: 8 times
Been thanked: 6 times

Re: JACK - latency compensation not staying the same

Post by Matt73 »

Hello Sir,

Interesting. Well I don't mind setting the latency compensation at the start of the session but it's a pain to constantly redo it every time there is an xrun. The playback is crystal clear with no pops or crackles but I do get quite a lot of xruns in a session. I think these are mostly caused when I fiddle with the plugins. I'm currently set at 48,000 with 256 buffer size and 3 periods. Should I really be aiming for 0 xruns?

The way I operate is to start JACK in studio controls, then open the DAW and run the latency detection and then open my test project where I play a drum trackand loop the headphones into the mic and record it onto another track. I then compare the two tracks. At the start it's pretty good, but I notice that the waveforms are not absolutely perfectly aligned. I can't detect any delay when I listen to it but there is a very slight visual misalignment when I zoom right in on the waveform. I am assuming that the waveform display is a faithful display of the track alignment. However, when I start recording, at some point the latency compensation changes. I know this because when I go back to the test project and test it and I see that the alignment has significantly shifted.

I don't seem to remember having this problem when I was using ALSA instead of JACK within the DAW but I like JACK because it seems to reduce latency when playing live MIDI instruments and I stopped having to constantly fiddle with the audio settings to get the audio to play without distortionas was the case when using ALSA within the DAW (The DAW I get 2 choices: ALSA and JACK).

Thanks for your kind help.

Best Wishes

Matt

Matt73
Established Member
Posts: 57
Joined: Fri Aug 27, 2021 5:07 am
Has thanked: 8 times
Been thanked: 6 times

Re: JACK - latency compensation not staying the same

Post by Matt73 »

Update: I upped the buffer from 256 to 512 and now I am getting zero x-runs and this shifting noo longer happens! I didn't realise x-runs could screw it up. The latency doesn't seem to have changed in any appreciable way in terms of time despite the higher buffer rate. Sometimes it's 1 millisecond sometimes 2. Sometimes it's somewhere in between. And then sometimes it gives a wild card reading of 13 or so. But if I just reset everything then it's generally around 1 to 2 milliseconds. And as long as I re-calibrate in the DAW before I start recording it's all good. I can't hear any lag whatsover. The groove is dead solid, but if I run a click sound from one track and record it on another through a headphones to mic loop, I can see that the waveform is very slightly off when I zoom right in. The second track looks ever so slightly late. The difference is so small that moving the vertical time line from one peak tip to the slightly later one doesn't even register on the beat counter which appears to go into thousands of a beat I think.

However, the perfectionist in me wants the loop test to sync up absolutely perfectly even when zoomed right in deep. I read that you can adjust the latency using the terminal and QJackCTL, and even gave it a try but it gave a latency of 32 milliseconds which is way off. Maybe I did it wrong. But if there is a latency compensation adjustment function in the DAW (which is JACK compatible) then why bother with testing it outside of the DAW?

User avatar
TheYke
Established Member
Posts: 53
Joined: Mon Dec 16, 2019 3:57 pm
Been thanked: 6 times

Re: JACK - latency compensation not staying the same

Post by TheYke »

Sorry for hijacking this thread but it seems my issue fits really well in here.

For me, as I work in audio for a living, it's crucial that latency is compensated spot on sample accurate. With classic jack and a simple loop-back test, I was able to compensate for timing offsets while recording using measurements and the recording settings tab in reaper.

However using pipewires jack-implementation the offset varies wildly for different buffersizes and even different measurements with the same buffersize. This is the case with an RME HDSPe PCIe card, on Fedora 37, tweaked for real-time use. no usb involved.

In fact, this is the only reason for me not to switch to pipewire, because otherwise it is much less of a hassle and with pretty decent overall latency, too.

Any advice what I might be missing here?

Post Reply