Development of a measuring device for audio latency with cheap and off-the-shelf components

[SurfingShroom]

Hi SOS-Community,

i'm writing my bachelor thesis at the University of Regensburg with the goal to develop a measurement device for the partial latency of audio hardware with cheap and off-the-shelf components. It would help me alot if professional or hobbyist musicians/audio engineers/music producers could help me to get a better view on the requirements by participating in my survey that takes about 10-15 minutes. You also can help me by simply distributing it to professional or hobbyist musicians/audio engineers/music producers. Thank you!

Link: https://docs.google.com/forms/d/e/1FAIp ... sp=sf_link

[Wonks]

It’s called a cable.

[Martin Walker]

Hi SurfingShroom, and welcome to the SOS Forums!

It’s called a cable.

That may sound flippant, but it's true - I've spent many years measuring latency in various forms (audio, MIDI etc.) for Sound On Sound reviews, and all you really need is a loopback cable.

More recently, quite a few audio interfaces themselves provide accurate readouts of real world latency (including that of their A/D and D/A converters) in supplied utilities, while many if not most DAWs now offer a way to measure real-time latency, if only so you can plug in audio hardware on an aux send/return without incurring any additional delays.

There's also lots of information about desired latency values for different applications, with drummers being the most sensitive.

Sorry!

Martin

[Wonks]

Yes, I meant to come back and expand upon my rather brief reply (I got sidetracked), but a loopback cable is all you really need to measure the audio latency of a typical audio interface with inputs and outputs for a given installation in a particular computer. Once you know that, you can then work out any added latency that software plugins add.

Some higher-end units with just inputs or just outputs won't work with this method on their own, but unless you are creating a purely record-only device with no monitoring (when latency doesn't matter), then you will almost certainly be partnering an all input unit with an all output or a mixed input/output unit, and you can still use the loopback cable method between two units.

It's the round trip latency that's important for recording whilst playing back at the same time. If you are simply mixing, it really doesn't matter (within reason). Knowing partial latencies really apply to software plugins and effects, so you can check that the latency they report to the DAW for playback timing corrections are the right values. But there are already utilities for doing that, as Martin said.

[SurfingShroom]

Hi SurfingShroom, and welcome to the SOS Forums!

It’s called a cable.

That may sound flippant, but it's true - I've spent many years measuring latency in various forms (audio, MIDI etc.) for Sound On Sound reviews, and all you really need is a loopback cable.

More recently, quite a few audio interfaces themselves provide accurate readouts of real world latency (including that of their A/D and D/A converters) in supplied utilities, while many if not most DAWs now offer a way to measure real-time latency, if only so you can plug in audio hardware on an aux send/return without incurring any additional delays.

There's also lots of information about desired latency values for different applications, with drummers being the most sensitive.

Sorry!

Martin

Thanks for your Feedback Martin and Wonks.

Still got some questions.

Isn't there internal error caused by the system youre running when measuring the round trip latency with a cable. For example the setup with jack_iodelay, described here https://wiki.linuxaudio.org/wiki/jack_l ... ncy_enigma, quotes in the section "JACK latency enigma", that it's still not possible to control the internal error caused by the system.

Can your described methods also measure latencies via other interfaces (USB, HDMI, ...)?

What about input/output only devices? How can you measure them. (My other motivation besides latency in the music environment is the latency of audio devices used in time critical experiments f.e. EEG, MEG, fMRI and other complex cognitive paradigms).

Can you tell me, which of the interfaces provide those readouts of real world latency? That sounds very interesting.

[James Perrett]

According to the article you link to

The USB driver adds an extra period or a 24 ms buffer, whichever is smaller.

which would therefore rule it out for any serious use. I've only dabbled in Linux audio but it seems that Jack adds an unnecessary layer of complexity if you are using a real DAW with decent internal routing.

[Folderol]

At best, Jack adds one buffer of delay. In this case it grabs all the inputs from all sources in one period and posts all the outputs wherever they need to go on the next (while fetching another lot of inputs). However I don't think there is anything that can process inputs and outputs directly. - You can't call something like a simple attenuator 'processing'!

This is complicated by the USB buffering itself which runs class compliant audio in fixed size blocks. Some proprietary hardware+software runs it's own USB code and buffering system eliminating this - thus giving better latency.

Of course most of this doesn't apply if you are running on a PCIe card

[Martin Walker]

Thanks for your Feedback Martin and Wonks.

Still got some questions.

Isn't there internal error caused by the system youre running when measuring the round trip latency with a cable. For example the setup with jack_iodelay, described here...

Can your described methods also measure latencies via other interfaces (USB, HDMI, ...)?

What about input/output only devices? How can you measure them. (My other motivation besides latency in the music environment is the latency of audio devices used in time critical experiments f.e. EEG, MEG, fMRI and other complex cognitive paradigms).

Can you tell me, which of the interfaces provide those readouts of real world latency? That sounds very interesting.

1. In most audio systems, the audio is essentially prepared a buffer's worth at a time, and then the just completed buffer data is pasted into the buffer itself, so that the audio stream is continuous and uninterrupted. So if you measure the round trip latency you are simply measuring the distance between the incoming (original) sound and the playback version, which equates to the size of the buffer(s).

There are indeed 'extras' involved, sometimes including an extra 'hidden' security buffer used by soome manufacturers, and of course the latency due to the A/D and D/A converters (although this is generally less than 1mS). However, these are constant extras, so I wouldn't describe them as 'internal errors' - they are simply part of the overall real world latency

If on the other hand you're referring to latency 'jitter', this shouldn't affect audio latency measurements, but does cause problem with MIDI latency, because the MIDI data is sent in packets, which typically results in timing jitter of up to 1mS when using standard MIDI Ins and Outs. However, if you use one of more modern USB MIDI connections the timing can get a lot tighter.

Here's a brief overview I wrote about the difference between MIDI and Audio latency:

https://www.soundonsound.com/techniques ... rity#para4

I also researched MIDI latency & jitter in more depth in a 2-part feature way back in SOS September & October 2002 if you want to find out more:

https://www.soundonsound.com/techniques ... ncy-part-1
https://www.soundonsound.com/techniques ... ncy-part-2

2. A loopback cable will enable you to measure real world latency with any format of audio interface, whether USB, PCI, PCIe, Firewire, Thunderbolt...

3. Input or output only devices can simply be measured using the corresponding part of a known device, so for example if you want to measure the latency of an input-only device you would connect it via a loopback cable to an output device whose real world latency you already know. Subtract one from the other and Bob's your uncle!

4. I've reviewed/measured over 80 audio interfaces since 1995, but haven't done so for some years now, so cant provide a totally up to date list. However, even when I was still measuring them, some manufacturers were already adding the static latency of their A/D and D/A converters to the user's chosen buffer size, ot provide an oven-ready readout of real world latency.

Hope this helps!

Martin

[merlyn]

... For example the setup with jack_iodelay, described here https://wiki.linuxaudio.org/wiki/jack_l ... ncy_enigma, quotes in the section "JACK latency enigma", that it's still not possible to control the internal error caused by the system.

At the top of the wiki page you linked to is this :

The creators of the wiki page then go onto say this :The information collected here is a first step: to make the issue clear to the authors. That particular page could be ten years old.

In other words what the linuxaudio wiki calls the JACK latency enigma is more of a question than an answer.

JACK adds zero latency. The latency is due to ALSA, which includes the USB drivers. I don't think Linux audio is too complicated, but if you're a double-click sort of guy, it might seem that way. This diagram gives us an idea :


What I think is the solution to the JACK latency enigma is that the UA-25 is a USB 2 interface and it's either been connected to a USB 1.1 port, or there is a USB 1.1 device on the bus, slowing the whole bus down. The anomaly in this plot could be explained by USB 1.1's higher latency than USB 2:


Doubling the buffer from 64 to 128 doesn't double the measured latency, meaning there is a constant extra latency being added to all the measurements which fits with the 2ms or 96 samples at 48kS/s minimum latency added with USB 1.1.

What that all means is that in no way does the wiki page suggest that there is a problem with jack_iodelay. The wiki page is about why there is extra measured latency. I've measured the latency of a Behringer UMC404 using USB 2 with jack_iodelay at 48kS/s and a 64 sample, 2 period buffer and I got 119 samples of extra latency, lower than the 200 odd in the plot above.