RTL Utility
RTL Utility is a tool for measuring the Round Trip Latency of your Digital Audio Workstation (DAW) and audio interface. The utility is used for low latency performance testing by system builders, reviewers, device manufacturers and at dawbench.com.
When your DAW sends data to your audio interface for playback, it doesn’t send a continuous stream of data one bit at a time. What it does is fill up a section of RAM called a buffer and sends that in a single message when it is ready. Before sending the next message it has to fill the buffer again. This wait time introduces a latency, or delay, between something happening in your DAW and when you actually hear it.
While you are recording, the audio interface buffers and sends data to your DAW in a similar fashion. This introduces latency into your recordings.
If you send a signal from your DAW, out through the audio interface and back in via a loopback patch, then there will be a round trip latency which is the sum of the output and input delays. This is the RTL.
Page contents
Downloads
User guide (PDF)| Version | Date | Builds | Changes |
|---|---|---|---|
| 1.0.8 | 28‑January‑2024 |
|
|
| 1.0.7 | 03‑June‑2023 |
|
|
| 1.0.6 | 22‑Jan‑2023 |
|
|
| 1.0.5 | 08‑Nov‑2022 |
|
|
| 1.0.4 | 24‑Apr‑2022 |
|
|
| 1.0.3 | 30‑Dec‑2021 |
|
|
| 1.0.2 | 18‑Nov‑2021 |
|
|
| 1.0.1 | 10‑Nov‑2021 | Bug fix for MOTU M4 devices enabling them to test at other sample rates | |
| 1.0.0 | 02‑Oct‑2021 |
New features
|
|
| 0.5.2 | 19‑Sep‑2020 |
|
|
| 0.5.1 | 16‑Apr‑2020 |
|
|
| 0.4.11 | 30‑Dec‑2018 |
|
|
| 0.4.10 | 03‑Nov‑2018 |
|
|
| 0.4.9 | 29‑Jul‑2018 |
|
How to handle issues with downloads
Problems opening old versions on macOS?
You may get warned against opening the app after download. For information on how to proceed, see here. TLDR; right-click or control-click then choose "Open".
Problems with SmartScreen on Windows?
We have registered RTL Utility with Microsoft but due to the relatively small number of downloads it may be flagged as unrecognised. If you get a notice that "Windows protected your PC" you may choose to click the "More info" link, then "Run anyway".
Windows dependencies
In order to run RTL Utility, you need to have Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019 installed. As this package is needed by lots of different applications, you probably already have it on your system. If not, you will get one of the following errors:
- The program can't start because vcruntime140_1.dll is missing from your computer. Try reinstalling the program to fix this problem.
- There was a problem starting vcruntime140_1.dll. The specified module could not be found.
- Error loading vcruntime140_1.dll. The specified module could not be found.
- The code execution cannot proceed because vcruntime140_1.dll was not found. Reinstalling the program may fix this problem.
- vcruntime140_1.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vender for support.
If you see any of these errors then please install the latest redistributable from here.
Linux dependencies
On Ubuntu and Raspberry Pi you will need to install the following dependencies:
sudo apt update
sudo apt install libasound2-dev libjack-jackd2-dev \
ladspa-sdk \
libcurl4-openssl-dev \
libfreetype6-dev \
libx11-dev libxcomposite-dev libxcursor-dev libxcursor-dev libxext-dev libxinerama-dev libxrandr-dev libxrender-dev \
libwebkit2gtk-4.0-dev \
libglu1-mesa-dev mesa-common-dev
FAQ
- Should Reported RTL match Measured RTL?
- Should I use Reported RTL or Measured RTL to offset my DAW?
- Reaper has offsets for input and output but RTL includes both input and output, what should I do?
- Does compensation matter at all when playing back or mixing at a larger buffer size setting?
- How much should I worry about latency offsets?
- Should the reported latency from my audio device include any internal processing performed within the device?
- What are the different elements of RTL?
- What affects RTL? Why do my measurements keep changing?
- Why is my measurement flagged as suspect?
- Why do I see a suspect flag at smaller buffer sizes, but not at large buffer sizes?
- What is the Return Level?
- How is the Return Level measured?
- What is the Noise Floor measurement?
- Why is the Noise Floor higher for higher sample rates?
- What is the Correlation Factor?
- Does my Correlation Factor indicate a good match?
- Can I use RTL Utility to test the latency of plugins?
- Does RTL Utility work with multi-channel plugins?
- Why am I seeing a message about audio glitching?
- Can I run other audio apps while running RTL Utility?
- Should I see my meters move when running a test?
- Which Ableton settings would you recommend for reduced latency?
- How can I make a latency measurement on a stand-alone device (e.g., a Raspberry Pi, or a hardware recorder)?
- Is there a version of RTL Utility that can work on Unix/Linux systems?
- Is there a command line version of RTL Utility?
- Is RTL Utility open source?
- How is the equivalent distance calculated?
- Why measure from software >> DAC >> ADC >> software when the real-world latency we are concerned with is ADC >> Software >> DAC?
- What are the OSX/macOS latency details?
Should Reported RTL match Measured RTL?
Yes! However, some audio interfaces are not as accurate in their reported figures as others, this is why we created RTL Utility :)
Should I use Reported RTL or Measured RTL to offset my DAW?
The automatic latency adjustment employed by most DAW applications relies on Reported RTL (i.e., the latency reported by the audio device driver). If the Reported RTL is not accurate, then recorded audio will not be placed in the correct position on the project timeline. If this is a problem for you, your DAW application may have a setting which allows you to offset the latency. This may be a relative offset in samples, or it may be an absolute value. If it’s a relative offset, then set the offset to the difference between Measured RTL and Reported RTL. If it’s an absolute offset, then set the offset to the Measured RTL.
In either case, be aware that the offset will likely vary depending on the buffer size and sample rate settings. Make sure you measure the RTL for each configuration that you intend to use.
Note: Reaper defaults to relative offsets, but you can enter absolute offsets if you untick “Use audio driver reported latency”.
Reaper has offsets for input and output but RTL includes both input and output, what should I do?
For syncing audio, I don't think it matters whether you use input or output latency offsets in Reaper – it's the total of the two that matters. Enter offset in either input or output (just not both!). Also make sure to use either the msec or samples input fields, not both!
If you need to synchronise audio and MIDI, then you may need to split the RTL offset between input and output. Unfortunately, while RTL Utility can tell you the reported input and output components, it can only measure the total round trip. You will have to experiment with different input and output offsets yourself in order to obtain perfect synchronisation.
Does compensation matter at all when playing back or mixing at a larger buffer size setting?
No, the compensation doesn't really matter for playback and mixing (unless you are using outboard effects). If you make sure things are aligned as you record, then you should be fine.
How much should I worry about latency offsets?
It really depends on you and what you would like to achieve. Timing accuracy is very important in some situations, but it’s important to have a sense of perspective. At 48kHz, a latency difference of 1 sample is equivalent to placing a microphone just 7mm further away from the sound source.
Should the reported latency from my audio device include any internal processing performed within the device?
Yes, devices should include any internal buffering in their reported latency. Otherwise, DAW applications can't correctly compensate for the delays.
What are the different elements of RTL?
RTL is composed of the delay due to output buffering in the DAW application, delays in your audio interface and the delay due to input buffering. Note that for analogue audio interfaces there are delays associated with A/D and D/A conversion, while for digital audio interfaces there may be delays associated with line transceivers and format conversion. If you have an acoustically coupled path (i.e., the signal path includes a speaker and a microphone), then there will be a latency component due to the acoustic delay (this is dependent on the distance between the speaker and the microphone).
What affects RTL? Why do my measurements keep changing?
Real-time audio processing is challenging for operating systems as they need to perform many tasks in parallel and manage different priorities. When you use small buffer sizes, it only takes a small delay in a higher priority task to cause an interruption to the audio stream. Hence choosing the right buffer size in your system is a trade-off between performance and stability. In addition to offering a variety of buffer size settings, some audio drivers offer “low latency” or “stable” modes. These generally relate to the size of safety buffers that the driver implements in addition to the standard buffer (or audio block) that is delivered to your DAW application for processing.
Here is a list of things which can affect RTL:
- Different buffer size settings (including settings for “low latency” or “stable” modes)
- Different sample rate settings
- Latencies can sometimes be different between the front and back inputs
- Some USB devices tend to have variability in latency with CoreAudio - this can be due to managing issues like having different clocks, and whether sound has to be synchronised with other devices
- Onboard DSP on your audio interface can affect latency and some devices have other features or options in their software mixer which can affect latency
- Whether your audio device is also being used as your system audio device
- Internal CoreAudio devices seem to introduce additional unreported latency on more recent Macs (possibly due to noise cancellation and other smart audio features)
We recommend that you run lots of tests under different conditions so that you understand what leads to variations in the RTL with your setup. Then control your conditions so you have a consistent experience.
Note for macOS: an audio driver called Blackhole can give you rock solid latency on macOS. Blackhole is normally used for syncing audio between apps, but you can set it up with a single audio interface and it will buffer the audio to give you reliable latency. Unfortunately, it will have a longer latency so that might not be an option for you.
Why is my measurement flagged as suspect?
A suspect measurement does not mean that the measured RTL is incorrect. It usually occurs because the measured RTL is quite different to what is reported by the audio device driver.
A measurement is flagged as a suspect result if any of the following conditions is true:
- The measured latency is less than zero
Obviously this should not be able to happen! If it did then it could be because a previous test signal was delayed by many seconds outside the computer, or there was an identical test signal generated by something else. The chances of this happening are virtually nil. - The measured latency is less than 99% of the reported latency
This occurs if the audio device driver reports a higher latency than the device provides. Don’t be too concerned if the latency is a little shorter than reported, as long as it is consistent. If it is a stable value, then you can adjust the latency compensation in your DAW application if you need perfect alignment. - The measured latency is greater than 125% of the reported latency
This happens quite often with ordinary soundcards on Windows. It also happens with internal mic/speakers on macOS (we suspect there is some extra noise cancelling processing which adds latency) - If there are more than three correlation peaks detected
RTL matches the return signal to the original signal by sliding one signal past the other in time and seeing how closely the signals correlate. Ideally, you’d have one position where the correlation is clearly better than anywhere else (a single correlation peak). However, the true peak may not align perfectly on a sample boundary and in this case, we may see peaks on either side of the true peak (i.e., three positions where the correlation is high). If we see more than three correlation peaks, then the signal has somehow been smeared and we can’t accurately determine the latency.
Why do I see a suspect flag at smaller buffer sizes, but not at large buffer sizes?
This can happen when a measurement is flagged as suspect because the RTL is less than 99% of the reported RTL. Often the difference between the measured and reported latencies is a fixed number of samples. Because our check is based on a percentage, the impact can be smaller at higher buffer sizes.
Imagine, for example, a device which always reports 10 samples less RTL than what is measured at any buffer size setting. If the device is set to 128 samples, and the reported RTL is 390 samples (with a measured RTL of 400 samples), then the reported is 97.5% of measured and the measurement is flagged as suspect. If the device is now set to 1024 samples and the reported RTL is 2390 samples (with a measured RTL of 2400 samples), then the reported is 99.6% of measured and the measurement is not flagged as suspect.
What is the Return Level?
The Return Level indicates how much the signal is reduced by the structure of your loopback connection and gain settings. If the signal is attenuated too much, then we can’t detect our test signal and make a valid measurement. To make a valid measurement, we need the Return Level to be at least 15dB higher than the noise floor. In practise, aim for something between 0dB and -20dB.
How is the Return Level measured?
RTL Utility generates a test signal with a number of peaks in it at known intervals. We look for these peaks in the return signal and measure their amplitude then average those results. In most test cases, the returned peaks should match the test signal peaks, however with an acoustically coupled measurement some of those peaks may be false due to noise (e.g. someone coughing) - hence the averaging.
What is the Noise Floor measurement?
The noise floor measurement in RTL Utility is a very simple measurement of how noisy the quiet bits of your audio are (i.e. the background hiss). If there is too much noise, it is hard to make a good measurement of the RTL. We include this measure to help diagnose how RTL measurements are being made (especially for acoustically coupled set ups). The measurement is not designed to give a reliable measurement of the noise floor of your audio interface – do not use it for benchmarking!
In RTL Utility, the measurement is made by analysing the first 1/8th of a second of audio, immediately before the test signal is generated. The RMS level is calculated across this short window and across the full audio spectrum. It is measured individually for all active input channels – however, the result is only recorded for the channel which has the strongest correlation to the expected test signal.
Before measurement, a default noise figure of -250.0dB is defined. If the measurement shows a noise figure of -250.0dB then that usually indicates a problem with the noise measurement as this could only be true if each sample in that 1/8th second window is 0 (zero!). This may be possible if your audio device implements a digital noise gate.
Why is the Noise Floor higher for higher sample rates?
This is just the law of physics at work, the wider the spectrum you are measuring, the more noise you collect. This can be mitigated by measuring noise only within a specific part of the audio spectrum, but RTL Utility is just doing a simple, full spectrum measurement of noise. That means that the noise floor rises as the bandwidth increases. Don’t be concerned about it, RTL Utility’s measurement is just a measurement of noise that you can't hear.
What is the Correlation Factor?
The Correlation Factor indicates how strongly we can match the return signal to the test signal using cross-correlation. In other words, we slide the return signal in time until we find the best match to the test signal. This gives us the time delta between the signals. What's important here is the relative correlation factors within the one measurement – we need to find a clear peak (the dark rectangle in the chart below which comes from the application log file).
RTL Measurement: Auto-correlation detection method, reported RTL = 653, return level = -6.6dB, noise floor = -111.0dB RTL Measurement: Ch = 1, correlation avg = 0.00017, correlation peak = 47.04377, correlation peak index = 654, number of peaks = 2, test pattern start = 5562, test pattern length = 200 RTL Measurement: Ch = 1, measured RTL = 653 RTL Measurement: Ch = 1, correlation chart: | ··---------------------=======--· -=oOO##▓█##OOo=-· ·--=======--------------------·· |
Does my Correlation Factor indicate a good match?
It doesn't really matter what value it is as long as it is above 1. It also doesn’t matter if it varies between different input/output pairs on your audio interface.
Can I use RTL Utility to test the latency of plugins?
RTL Utility has been designed to measure the latency of audio interfaces rather than plugins, but there is a way you might be able to achieve this. The challenge is to get the audio to pass from the RTL Utility app, into a DAW and then out again to RTL Utility. This is possible if you have two separate systems.
You will need two computers, each with an audio interface. The first will be the “analyser” and will be running RTL Utility. The second will be running your DAW, hosting the plugin. Connect the output of the “analyser” to the input of the DAW machine. Then connect the output of the DAW machine to the input of the “analyser”. This should complete a round trip which you can then measure. Of course, you’ll need to make sure record monitoring is on so that the sound passes through the DAW.
First measure the RTL with the plugin bypassed. Press the Store/Compare button in RTL Utility, then make another measurement with the plugin enabled. Now if you hover over the measured RTL you’ll get a tooltip showing the delta from the previous measurement. This will be the latency introduced by enabling the plugin.
It may be possible to do this on one computer with two interfaces, but I haven’t tried it and it might introduce some other variables.
BTW, if you didn’t already know, many DAW applications can report plugin latency – e.g. just google “Cubase show plugin latency”.
Does RTL Utility work with multi-channel plugins?
RTL Utility is designed to work with audio interfaces rather than plugins. It can make measurements across audio streams made available from an audio device driver, but it has no capability for hosting plugins.
The software is capable of multi-channel operation – it broadcasts the test signal on all active outputs and listens to all active inputs for a result. However, only a single result is recorded for the various inputs (the user would need to manually activate individual channels to get specific per-channel measurements).
Why am I seeing a message about audio glitching?
This means the audio device driver has reported either a buffer overrun or an underrun. Overrun means the driver can't keep up with the data as it is coming in, while underrun means the data isn't coming in fast enough to maintain a real time stream. RTL Utility can’t detect whether it is under or over, just that there was an issue.
If the audio has glitched, then the measurement is invalidated.
Can I run other audio apps while running RTL Utility?
You can, but it is not recommended because:
- Other audio apps might re-route or process the signal and invalidate the measurement
- Other audio apps might try to enforce an exclusive audio mode
- On macOS: if multiple apps are using audio at the same time, then CoreAudio must mix the different sources. We've noticed that if we open another audio app, the measured latency increases and stays there until the audio device is reset. This behaviour may vary depending on your device.
Should I see my meters move when running a test?
The audio pulse is quite short, but you do normally see it on meters. If the meters aren't moving then either the routing isn't set up correctly, or there is some sort of processing issue.
Which Ableton settings would you recommend for reduced latency?
Like all major DAW applications, Ableton supports latency compensation. Here are a couple of references which may help:
- Ableton Delay Compensation FAQ (note the section that describes what things aren't compensated)
- Ableton Live Insider Tips: Force Real-Time Rendering...
How can I make a latency measurement on a stand-alone device (e.g., a Raspberry Pi, or a hardware recorder)?
What you can do is set up a PC or Mac with an audio interface and baseline it's latency, then do an audio patch through the stand-alone device and measure the difference. Here are the steps:
- Make a normal measurement of RTL on the PC using a straight loopback cable
- Click the Store/Compare button
- Connect the output of the PC to the input of the standalone device
- Connect the output of the standalone device to the input of the PC
- Run an audio loopback on the stand-alone device (i.e., make sure the input is routed directly to the output)
- Make a new measurement of RTL on the PC
- Hover over the new RTL result and you'll see the delta reported in the tooltip – this will be the RTL of the stand-alone device
Is there a version of RTL Utility that can work on Unix/Linux systems?
Yes, but only for selected distros.
Is there a command line version of RTL Utility?
No
Is RTL Utility open source?
No
How is the equivalent distance calculated?
The distance equivalent for an RTL measurement is calculated using 343mm/msec for the speed of sound. This gets displayed in a tooltip for comparisons made against a stored measurement.
Why measure from software >> DAC >> ADC >> software when the real-world latency we are concerned with is ADC >> Software >> DAC?
RTL Utility is focused on assessing the latency for the audio interface hardware, device drivers and Operating System as seen from your computer. Measuring ADC >> Software >> DAC requires a second system, i.e., it needs to be measured out of the box. If your audio is not glitching, then the OS/driver part of the software has a fixed latency relating to the block size. Seeing as we know what that is, then there is little to be gained by going to the expense of setting up a second system. If your DAW software or plugins are adding additional latency, then that is not something that RTL Utility measures - but most DAWs report that additional latency anyhow.
What are the OSX/macOS latency details?
The CoreAudio system on macOS provides additional insights into different elements of latency reported by an audio device. You can see this information in RTL Utility by right-clicking the header of the results table and enabling the relevant columns.
- Buffer frame size relates to the buffer size setting in your DAW application
- Device latency accounts for any added latency in that audio device which affects all audio streams independent of the buffer size
- Safety offset is extra buffering to account for variables like hardware clock jitter
- Stream latency is the same as device latency, but specific to a stream (RTL Utility doesn’t use a specific stream, so this should be zero)