Audio delay inconsistent


I just recently bought a Behringer UMC1820 which is otherwise performing perfectly and seems to match all my requirements. However, I noticed that if I re-use my previous sample setting for input/output delay Ardour’s track recording is still slightly “off” the beat (I tested by recording the metronome from ardour and routing that straight from output -> input). If I re-do the delay test in Ardour then I get a slightly different delay amount (usually within ~10 sample rate difference, but at least one point it was 20 samples faster than usual), and then I re-record and the recorded click lines up again.

Is there something wrong with my audio interface? Or is it to be expected that I have to re-run the audio config wizard each time I record to get the recording perfectly in-sync?

Also, I’m a little concerned since most of my recording done is via SPDIF which I’m not using for the delay test. Wouldn’t SPDIF have a different latency since there is no A/D conversion?

I also tried starting/stopping different programs and it seemed to have little to no effect on latency.

Unfortunately, all USB audio devices on Linux suffer from variable “hardware” or “systemic” latency every time they are restarted. It can be measured and compensated for, but there’s nothing we can do (as application developers or users) to remove the variation.

1 Like

Thank you! Good to know it is not unusual, I was worried something was wrong with my interface since I really am growing attached to it.

What is the source of this issue? Is this something wrong on the kernel side?

Yes, it’s a kernel side issue. A few others here can comment on the details of it more authoritatively than me. There have been a few proposals to fix it, but as far as I know no agreement to do so.

It should be constant as long as the device is kept running (and no x-run happens).

For USB devices the Linux kernel driver add some additional buffering. Depending when the device is started relative to USB bus availability, there is extra systemic latency due to that buffer. This is specific to USB; PCI[e] and firewire devices are not affected.

For that reason Ardour/ALSA allows to calibrate the systemic latency without restarting the engine (JACK does not offer this).

Yes it is a theoretical problem but should be put into perspective. At 48 kHz sample rate 1 ms is 48 samples. So you have observed a 0.5 ms error (correct me if I calculated it incorrectly). A human playing an instrument is much much more inaccurate. Imho you can just ignore the error unless you are doing some very unusual stuff. I usually take 10 - 20 measurements of a new USB device and then just use the average of those as the default.

1 Like

That is a reasonable approach for recording music (assuming it doesn’t vary too much).

To put things into perspective. In 1ms, sound travels 1ft (~30cm) in air. Many musicians move around a lot more.

PS. However if you do repetitive bounces through external equipment, you may want to calibrate every time.

Wow, I did not realize it was that small of a difference. That seems weird to me though since with as much of a 10 sample rate difference, there was a very audible difference in the click track. I feel like <1ms would not be noticeable in that case.

I’m recording in 44.1khz.