Latency: how to solve over-correction

Installation & Configuration Mac OS X
#1

Hey, new user here. Issue is pretty straightforward:

Latency is being over-corrected by ~6 ms.

Ardour seems lovely and a good fit for me, but this is a deal-killer if I can’t solve.

Details:

Mac mini, 64 bit Ardour 5.12.0, Behringer umc404hd interface over usb.

At startup, run the ‘Calibrate Audio’ button. Very consistent readings of:

detected roundtrip latency: 2274 samples
systemic latency: -59 samples
(at 48k sampling rate)

Three user settings which appear to have no actual effect:

Hardware input latency
Hardware output latency
(both fields in the startup dialog)
Adjust Latency in the individual track pop-up menu

So by trial and error I have found that those settings have no effect, and new tracks are consistently recorded ~6ms ahead of existing tracks.

Thanks for any help!

#2

I have yet to dig into running this with ALSA, but is there a way to specify the buffer size? This would seem to also affect latency.

Bob

#3

You may also want to review the jack documentation, typically when you measure the latency you assume that the input side and the output side of your interface are nearly symmetrical, and split the measured delay into equal input latency and output latency values. I would assume that the Ardour automated measurement does that for you when using the ALSA backend and initiating the latency measurement process, but I am not sure, I have not tried it personally.

#4

JACK on macOS still uses CoreAudio. There’s no other way to get audio data in and out of macOS applications.

Also, you don’t need to use JACK on Linux either - Ardour’s own ALSA audio/MIDI backend will serve most people’s needs most of the time.

#5

@x42

Thank you very much. That’s essentially the conclusion I came to. So CoreAudio is the problem.

In the meanwhile, I did an install on a linux laptop. Using Jack and repeating the same methods**, I quickly got a scenario where latency is repeatedly +6 samples. Hooray!

It does appear that Jack is available for os X. So using that instead of CoreAudio is another potential solution, in addition to what you mentioned.

Thanks again…will post back if I explore Jack on the Mac. For the moment, I’m going to test some other stuff on the linux box.

**This isn’t the linux forum, but in case it helps someone in the future: There is no startup screen with the ‘calibrate’ option like with Ardour on osX. Latency is 100% handled by Jack. So a quick bit of trial and error to set the correct flag value, and success. -O is how you set output latency in Jack, so ultimately my command to launch from terminal is like so:

jackd -d alsa --device hw:1 -O 653

653 is the value for delaying playback output to compensate for latency. Anyway, Jackd has a perfectly good man page.

#6

tl;dr: you cannot.

Ardour uses at least the latency that is reported by Apple’s CoreAudio. This cannot be disabled.

When you measure “systemic latency: -59 sample”, “systemic latency: -59 samples”, negative values have no effect and mean that Apple’s CoreAudio System over-reports the latency of the soundcard. You can only compensate for actual latency (positive systemic latency) add more latency and it will be even more overcompensated.

I don’t know how Mac interacts with umc404hd to query the latency of the hardware, but You may be able to work around this by using Apple’s AUDIO/MIDI Setup tool and create an aggregate device.

#7

How did you run the calibrate audio? Did you connect a cable between the audio interface input and output so that the full roundtrip latency could be measured?

#8

@ccaudle

Yes, exactly.

So next I record a click track, monitor/record that straight through the interface. After recording, the new track is consistently 6ms in front of the playback track.