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.

You'll need a physical loopback patch to measure RTL

RTL Utility is free for use, however if you would like to contribute towards its development, then you are most welcome to do so!

Page contents



User guide (PDF)

Version Date Builds Changes
1.0.8 28‑January‑2024
  • Prevent ghost measurements when inputs are floating
  • Added binaries for Ubuntu 22.04 and Raspberry Pi 4 (see Linux dependencies)
  • 10‑March‑2024: the macOS file has been replaced with a version which corrects issues with microphone permissions and backward compatibility to macOS 10.13 (High Sierra). You may need to refresh your browser cache as the file name has not been changed.
1.0.7 03‑June‑2023
  • Windows: bugfix to avoid crashes when initialising ASIO drivers based on PortAudio (FlexASIO, KoordASIO)
  • Added spinner while initialising audio devices on app launch
1.0.6 22‑Jan‑2023
  • Added extended mode measurements (can test latencies up to ~5 seconds)
  • macOS fix for deselecting anything but last channel
1.0.5 08‑Nov‑2022
  • Windows excecutables are now signed by Oblique Audio
  • macOs app is now signed by Andrew Jerrim and distributed as a notarized dmg
  • App launch times reduced by delaying initialisation of AudioDevices
  • CSV export button added to log tab
  • macOS: accuracy of reported latency improved for built-in devices (no change to measurements)
  • macOS: tweaked how latency components are formatted in RTL tooltip and added extra columns to log table
  • Windows: ASIO fix for some Denon DJ interfaces
1.0.4 24‑Apr‑2022
  • Added a column for user notes to the log table (double click to edit)
  • Better detection of sample rate changes from device's own control panel (or from Audio & Midi settings on macOS)
  • Test now fails and aborts if device is reconfigured externally
  • More informative notifications when test signal not detected
  • Improved font rendering on lower resolution monitors
  • Fixed issue with initial sort order of log table
  • Styling tweaks
1.0.3 30‑Dec‑2021
  • Fixed bug causing crashes when trying to select WASAPI (Windows Audio) devices
1.0.2 18‑Nov‑2021
  • Fixed issue where some devices would have incorrect measurements for buffer sizes larger than 2048 samples
  • Fixed issue where the clear log buttons had no effect - sorry about that!
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
  • Completely new & robust detection algorithm which performs optimally for both clean and noisy loopback paths
    • Works nicely for loopback paths with acoustic coupling, e.g. PA system measurements. Note that the RTL will include the delay due to the physical distance between the transducers.
    • If multiple channels are tested at the same time, only the result for the best channel will be recorded.
  • The results table on the Log tab has been updated
    • History from previous runs is now retained
    • You can delete a row by selecting it and pressing the delete key
    • You can sort the table by clicking on a column header
    • Column settings will be persisted between sessions
    • You can click a button to reset to the default layout
    • You will now be asked to confirm if you want to clear the log table
  • Added details of the components of latency for CoreAudio (device latency, safety offset and stream latency)
  • The tooltip for the msec result now shows the equivalent distance for the delta between stored and current measurement (assuming speed of sound = 343 m/s)
  • Added support for sample rates up to 768 kHz and samples sizes of 32768
  • Added an application debug log which includes audio device and RTL measurement debug info (including a chart of the detection output)
  • You can now zoom the GUI (use the buttons in the bottom right, or Ctrl + Mouse Wheel on the background, double-click on background to reset)
  • Previous size of the application window, zoom level and full screen status are restored at launch
  • Improved handling of external buffer size changes so that the app updates correctly (e.g. with RME devices)
  • The audio device manager now refreshes available buffer sizes after the sample rate is changed (e.g. with RME devices)
Other improvements
  • Replaced return loss with return level (e.g. a return loss of 11.0 dB will now be referred to as a return level of -11.0 dB)
  • Added Reported RTL to the most recent results panel (now show this and signal quality metrics even if measurement was invalid)
  • Added warning that measuring RTL using Windows Audio is not recommended (use ASIO instead)
  • Warnings about suspect results are now shown on the most recent results panel instead of showing an alert window
0.5.2 19‑Sep‑2020
  • Reinstated manual tweaks to latency reported by driver for CoreAudio (fixes reported latency on macOS)
  • Just for Vin - show RTL (msec) to 3 decimal places
  • Fixed issues with https so version check works on macOS
0.5.1 16‑Apr‑2020
  • Improved latency measurement algorithm for acoustically coupled measurements
  • Removed manual tweaks to latency reported by driver (doesn't affect measurement)
  • Added feature to store measurement (comparisons shown in tooltips)
  • Added warning if driver reports buffer underrun or overrun
  • Updated and re-ordered columns in table and log file
0.4.11 30‑Dec‑2018
  • Increased robustness of the latency measurement algorithm
  • Slightly improved audio device compatibility (more tolerant of larger buffer sizes and higher channel counts)
  • Corrected return loss measurements
  • Minor GUI tweaks & fixes
0.4.10 03‑Nov‑2018
  • Fresh build with latest from the JUCE develop branch (including lower sample rate options)
  • macOS build not updated
0.4.9 29‑Jul‑2018
  • Fixed issue where invalid measurements where being logged as valid
  • Added macOS build


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:

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





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:

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:

  1. 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.
  2. 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.
  3. 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)
  4. 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:

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:

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:

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?


Is RTL Utility open source?


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.