I have measured hardware latency using the Ardour6 “Audio/MIDI Setup” dialog multiple times (once per day or so) and I got differing results (differs about 12ms=600 samples). That means that after the calibration, latency compensation works perfect, but when hardware latency changes, the old correction values are wrong and my recordings are out of sync. At the moment I cannot reliably reproduce the problem; it just happens from time to time.
I thought hardware latency is (roughly) constant. Do you have an idea what could possibly cause this big deviation?
I use a Focusrite Scarlett 6i6 1st gen USB audio interface with a thinkpad X250 laptop. I use Linux Mint 19.3, but with an realtime kernel (which is not strictly necessary for me, because I use direct monitoring anyway).
I use alsa (not jack), 48kHz, 1024 samples, 2 periods. I configure all this within Ardour6, using the Audio setup dialog.
I check the settings from time to time by routing Ardour’s click over a cable and then recording it. When playing, the recording should be in perfect sync with Ardour’s click. With a fresh calibration, this is the case.
My measurements differ by about 600 samples@48KHz=12ms. I.e. the hardware input and output latency settings differ by 300 each.
USB devices on Linux have different systemic latency every time they’re started (and every time after a x-run). This is due to additional kernel side buffering.
PCI[e] and Firewire devices are not affected by this.
There is a technical explanation by ALSA developer Clemens Ladisch in this thread in jack-devel. The USB driver adds up to an extra period, but at most a 24 ms buffer.
I have read about this issue with USB devices several times which confirmed that my experience was not caused by my hardware’s fault (for instance, here, and here I explained my experience with Focusrite Scarlett 18i20). Sincerely, I felt sad discovering this, because in my opinion this issue discards Linux for USB “pro” audio. Nowadays, there are more and more USB devices that work in Linux in Class Compliant mode, and it’s clear that it’s something that more users will experience if they decide to give Linux a try. So, we might see more reports about this.
Since obviously this is not an Ardour issue, but an ALSA issue, we might send our experiences to firstname.lastname@example.org So, we can let ALSA developers know that this issue is really affecting users.
Thanks for this valuable information. My workaround will be to recalibrate at the start of each recording session and use big buffers (to avoid xruns).
It would be nice to see this info appear in the Ardour manual hint
Every non-generated page of the manual can be edited at github. Find this logo near the upper right of each page:
Click it, do the edit, and we will get a pull request.
Nice feature I will try to write a bit as soon as I can get time for it.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.