I just completed a loopback session with my audio interface to determine the latency and compensated in samples. Is there a recent latency app that performs this task?

 

I found it . . . RTL Utility!

 

Are you recording live instruments/vocals? I'm having a hard time figuring out what obtaining the Magic Number would fix for me?

 

I created a loopback using an instrument cable, then used RTL Utility. The measured latency was almost identical to the figure I came up with doing this manually by following Kenny Gioia's YouTube tutorial whereby you have a kick sample on track one, then record the loopback kick on track two. Then you place markers between and measure the gap.

 

I understand that part. But if you are using Logic, it has External Instrument Latency Compensation. So if you are recording hardware synthesizers which are driven by MIDI data inside Logic; the hardware latency compensation deals with it automatically. If you are using hardware effects to send to (print loop); before you begin sending audio, you send a ping and it measures the total amount of round trip latency and Logic then compensates for it also. If you "live play" keys in via midi to record the Midi, almost any quantization setting will be more rigid than some small amount milliseconds of latency.

What are you recording that you need this app's functionality for?

 

I switched to Reaper, and the reported latency is wacky. It reports more than needed . . . like some kind of reverse latency. I am not worried about MIDI, just live instruments. Thanks for your thoughts, Clone.

 

The only way to be absolutely sure you measure the real delay is by using two DAWs and Interfaces. That's the way I do it:

DAW one is the "measuring instrument". DAW two and the audio interface to be measured is connected as a "real time FX processor". Analog output 1 of the measuring DAW is directly connected to analog input 1 by cable. Analog output 2 is connected "through" to the input of the 2nd interface and the output back to input 2 of the measuring DAW. Hope that's clear enough.

So the left channel of a stereo signal is simply recorded through DA/AD of the "measuring interface". Latency correction of the driver should result in a (almost) perfect zero delay.

The right channel is recorded the same way, but additionally through AD/DA, driver and processing of the second interface. So there is no chance of any driver delay compensation to mess up the measurement, as it's connected analog.

Any signal you play and record this way has a delay on the second channel which represents the real world latency of the second interface and DAW and can not be "fooled" by latency compensation or driver reporting to the DAW.

So far I know RME is the only manufacturer giving you FULL specs of their devices and drivers. I tried it with my Babyface Pro FS and my measurements accurately match these specs.

For example: using macOS, Core Audio is using a small buffer for recording and playback of 16 samples each. The Interface uses a small safety buffer of 32 samples for playback to stabilize performance. The BF Pro FS has very fast AD and DA converters which only need 5 samples AD and 7 samples DA at 44.1kHz.

Using 44.1 kHz sample rate and a buffer size of 64 this results in 5 + 16 + 64 + 64 + 16 + 32 + 7 = 204 samples or 4.6ms delay. And this is exactly what I measured myself.

Using Windows ASIO drivers, it is even faster because the 16 + 16 samples delay of core audio are absent. This results in 172 samples or 3.9ms delay @ 44.1kHz.

This should be perfectly fine for all recording situations and even the tightest players as it's approximately 1.5m distance to a speaker.

Even vocal tracking is ok, but you can "feel" the delay in form of a filtering effect in your head itself, as the sound of the headphones is a bit later then the sound going through your bones directly to the ear. Flipping the phase of the headphones can sound better.

In my opinion, anything less than 64 samples buffer size makes not much sense, even at 44.1kHz, as processing power goes up significantly.

If you want it really fast, use 96kHz and 64 samples buffer, this gives you 2.1ms RTL on macOS and 1.8ms on Windows!

 

Thanks for taking the time to write in details, Myfanwy. I am currently using 48k/64buf. With RTL Utility . . .

Reported RTL: 429
Measured RTL: 369

When I did the loopback test with 2 channels, I got 374. Some users suggest I leave the reported and adjust, but my reported actually created a reverse latency when I did the manual test with two tracks in Reaper.

 

That is why I have built this whole "analog path" measuring setup. There is simply no possibilty to fake any values as you can't compensate anything or report wrong values along the real time analog signal.

Edit: By the way, you can do this with any second interface as a measurement tool, as the quality or latency of the interface is not affecting the accuracy of the measurement at all, as both channels of a stereo signal are in phase, even with the cheapest ones, and only the time difference of both channels displays the RTL of the measured interface.

 

Last edited: Aug 13, 2023