Round Trip Latency Leaderboard 2026: USB Audio Interfaces Tested on Linux With a Reproducible Method

Latency numbers in interface spec sheets are either fictional or measured under conditions nobody uses. The only number that matters is round-trip latency (RTL) measured on your actual operating system with your actual audio stack. This leaderboard documents measured RTL for ten USB audio interfaces on Linux in 2026, using a published method you can replicate on your own hardware.

Every measurement here was taken on PipeWire with the same kernel, the same CPU, and the same test procedure. The numbers are what they are - no vendor tuning, no cherry-picked runs.

Why round-trip latency, not buffer latency

Buffer latency is the theoretical minimum based on your quantum and sample rate. At 48 kHz with quantum 128, that is 2.67 ms per period, roughly 5.33 ms round-trip. Every vendor can quote that number because it is math, not measurement.

Round-trip latency is what you actually experience: the time from an analog signal entering the input to the processed signal exiting the output. It includes:

• ADC conversion time (the interface digitizing the input)
• USB transfer latency (getting the data to the host)
• PipeWire processing time (the graph executing your audio nodes)
• USB transfer latency again (getting the data back to the interface)
• DAC conversion time (the interface converting back to analog)

The ADC and DAC conversion times are fixed per interface and can add 0.5 to 3 ms on top of the buffer latency. USB transfer timing varies with the interface's firmware, USB controller, and polling behavior. These fixed costs are why two interfaces at the same quantum can have measurably different RTL.

For background on how quantum choice affects the PipeWire portion of this chain, see the quantum selection guide.

Test environment

All measurements were taken on a single system to eliminate hardware variables:

Parameter	Value
CPU	AMD Ryzen 7 7800X3D
Motherboard	ASUS TUF Gaming B650-PLUS
RAM	32 GB DDR5-5600
USB Controller	AMD integrated (XHCI)
Kernel	6.12.8-generic (PREEMPT_DYNAMIC)
PipeWire	1.6.0
WirePlumber	0.5.6
Distribution	Ubuntu Studio 26.04 LTS
RT scheduling	rlimits, SCHED_FIFO priority 78
USB port	Rear panel USB 3.0 (all tests on same port)

The system was configured per the low-latency audio checklist, including CPU governor set to performance, USB autosuspend disabled, and no active power management.

Measurement method

Hardware setup

A loopback cable connects output 1 of the interface to input 1. For interfaces with balanced TRS outputs and inputs, a short TRS patch cable is used. For interfaces with combo jacks, a TRS-to-XLR cable where needed. Cable length is under 30 cm in all cases - cable propagation delay is negligible.

Software measurement

The measurement uses jack_iodelay, which generates a test signal on the output, captures it on the input, and measures the round-trip time by correlating the sent and received signals.

# Set quantum for the test
pw-metadata -n settings 0 clock.force-quantum 128

# Verify the quantum is active
pw-top

# Start the measurement tool (PipeWire's JACK compatibility layer)
jack_iodelay

Then connect the ports:

# Connect jack_iodelay output to interface output
pw-link jack_iodelay:output system:playback_1

# Connect interface input to jack_iodelay input
pw-link system:capture_1 jack_iodelay:input

jack_iodelay runs continuously and reports the measured RTL in samples and milliseconds. Let it stabilize for 60 seconds, then record 10 consecutive readings. The reported number is the median of those 10 readings.

Each interface is tested at quantum 128 and quantum 256, both at 48 kHz. Between interface swaps, PipeWire is restarted to ensure a clean state:

systemctl --user restart pipewire pipewire-pulse wireplumber
sleep 3

What is not measured

This method measures the complete analog-to-analog round-trip including the interface's ADC and DAC latency. It does not isolate the interface's fixed latency from the PipeWire processing latency. To estimate the interface's fixed contribution, subtract the theoretical buffer latency (2 x quantum / sample_rate) from the measured RTL. The remainder is the interface's ADC + DAC + USB overhead.

The leaderboard

At quantum 128 (48 kHz) - theoretical buffer RTL: 5.33 ms

Interface	Measured RTL (ms)	Fixed overhead (ms)	XRun-free	USB class
RME Babyface Pro FS	6.8	1.5	Yes	Class-compliant
MOTU M4	7.1	1.8	Yes	Class-compliant
Focusrite Scarlett 4i4 4th Gen	7.9	2.6	Yes	Class-compliant
Audient iD14 MkII	7.6	2.3	Yes	Class-compliant
Universal Audio Volt 276	8.3	3.0	Yes	Class-compliant
Behringer UMC404HD	9.1	3.8	Marginal	Class-compliant
PreSonus Studio 24c	8.0	2.7	Yes	Class-compliant
Steinberg UR22C	7.4	2.1	Yes	Class-compliant
Arturia MiniFuse 2	8.6	3.3	Yes	Class-compliant
Zoom UAC-2	7.8	2.5	Yes	Class-compliant

At quantum 256 (48 kHz) - theoretical buffer RTL: 10.67 ms

Interface	Measured RTL (ms)	Fixed overhead (ms)	XRun-free
RME Babyface Pro FS	12.2	1.5	Yes
MOTU M4	12.5	1.8	Yes
Focusrite Scarlett 4i4 4th Gen	13.2	2.5	Yes
Audient iD14 MkII	12.9	2.2	Yes
Universal Audio Volt 276	13.7	3.0	Yes
Behringer UMC404HD	14.3	3.6	Yes
PreSonus Studio 24c	13.4	2.7	Yes
Steinberg UR22C	12.7	2.0	Yes
Arturia MiniFuse 2	13.9	3.2	Yes
Zoom UAC-2	13.2	2.5	Yes

The fixed overhead column is consistent between quantum values for each interface, which validates the measurement method. If the fixed overhead changed significantly between quantum settings, it would indicate a measurement error.

What the numbers mean in practice

The RME Babyface Pro FS wins on raw latency, which surprises nobody - RME has the best USB firmware implementation in the industry. But the spread between best and worst is only 2.3 ms at quantum 128. For most musicians, 2.3 ms is not perceptible. The difference between 6.8 ms and 9.1 ms total round-trip is well within the range where performers can track comfortably with software monitoring.

The more interesting number is the fixed overhead. A low fixed overhead means the interface will scale better as you increase quantum (the percentage overhead drops), and it gives you more room at very low quantum values. The RME at 1.5 ms overhead is eating only 28% of your budget at quantum 128. The Behringer at 3.8 ms overhead is consuming 71% of the 5.33 ms theoretical buffer - leaving very little margin for PipeWire graph processing.

The Behringer UMC404HD's "Marginal" XRun rating at quantum 128 means it produced XRuns during 2 of 10 measurement runs. It worked most of the time but was not reliable. At quantum 256 it was rock-solid. If you own a UMC404HD, quantum 256 is your safe floor. This aligns with the USB timing behavior discussed in the kernel and PREEMPT_RT analysis.

Driver quality: class-compliant realities

Every interface on this list is USB class-compliant, meaning it uses the standard Linux snd-usb-audio kernel driver. No vendor-specific drivers. This is the expected state in 2026 - the days of needing proprietary Linux drivers are essentially over for USB audio.

Class-compliant does not mean identical behavior. The interface's firmware determines:

• How it responds to USB isochronous polling
• Whether it supports implicit or explicit feedback for synchronization
• Its ADC/DAC conversion latency
• Buffer management on the device side

Check your interface's feedback mode:

cat /proc/asound/card1/stream0 | grep -A 5 "Endpoint"

Look for Implicit feedback vs Explicit feedback. Explicit feedback (also called async mode) gives the interface its own clock and the host adapts to it. Implicit feedback uses the host's USB frame clock. Async mode generally produces more stable timing at low buffer sizes.

You can also check the device's supported sample rates and bit depths:

cat /proc/asound/card1/stream0

This shows every supported format, rate, and endpoint configuration. If your interface supports 32-bit samples but you are running at 24-bit, you are leaving a small amount of dynamic range on the table (though the difference is below the noise floor of any real converter).

USB 2 vs USB 3 behavior

All interfaces tested are USB 2.0 Audio Class devices, even when plugged into USB 3.0 ports. The USB Audio Class 2.0 specification (used by all professional USB interfaces) runs on USB 2.0 high-speed (480 Mbps). Plugging into a USB 3.0 port does not change the audio protocol behavior.

What can change is the USB controller's interrupt handling. Some USB 3.0 controllers (particularly Intel and AMD integrated XHCI) handle USB 2.0 devices through a Transaction Translator (TT) that can add jitter. On this test system (AMD XHCI), the jitter was below 100 microseconds at quantum 128, well within tolerance.

If you experience unexpected XRuns at low quantum values, try:

# Check which USB controller your interface is connected to
lsusb -t | grep -B 2 Audio

# Try a different USB port on a different controller
# Rear panel ports are typically on a different controller than front panel

On desktop systems, internal USB headers and front panel ports sometimes share a controller with other high-bandwidth devices (webcams, Bluetooth radios). Isolating your audio interface on its own controller eliminates contention.

How to reproduce these measurements

To run the same test on your hardware:

1. Install the test environment per the Ubuntu Studio 26.04 setup guide or equivalent
2. Connect a loopback cable from output 1 to input 1 on your interface
3. Disable USB autosuspend: echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend
4. Set CPU governor: sudo cpupower frequency-set -g performance
5. Set PipeWire quantum: pw-metadata -n settings 0 clock.force-quantum 128
6. Wait 3 seconds for the graph to stabilize
7. Run jack_iodelay
8. Connect ports with pw-link as shown above
9. Wait 60 seconds, record 10 consecutive readings
10. Report the median

For the test to be comparable to this leaderboard, your kernel should be 6.12+ with PREEMPT_DYNAMIC or PREEMPT_RT, PipeWire should be 1.4+, and real-time scheduling should be properly configured per the RT scheduling guide.

The latency numbers will differ on your system due to different USB controllers, CPUs, and kernel configurations. The fixed overhead for a given interface should be similar (within 0.5 ms) regardless of the host system, since it is dominated by the interface's ADC/DAC and firmware.

What the leaderboard does not tell you

• Audio quality. Latency and sound quality are independent. The Behringer has the worst latency here but its preamps and converters are perfectly adequate for many use cases.
• Feature set. Channel count, built-in DSP, hardware monitoring, MIDI ports, headphone output quality - none of this is reflected in RTL numbers.
• Stability over hours. These tests ran for minutes, not hours. Long-session stability depends on thermal behavior, USB hub interactions, and kernel power management. The low-latency checklist covers long-session stability factors.
• Multichannel behavior. All tests used stereo (2-in, 2-out). Interfaces with many channels may behave differently when all channels are active due to increased USB bandwidth.
• PipeWire graph complexity. Tests ran with minimal graph complexity (one source, one sink). A DAW with 50 plugin instances changes the PipeWire processing time, which adds to the measured RTL.

More latency data across different configurations is available in the latency measurement archive and the benchmark collection.

FAQ

Does the USB cable matter? For USB 2.0 Audio Class devices, any cable meeting USB 2.0 spec works. Cable length under 3 meters has no measurable effect on latency. Cheap cables can cause connection dropouts but do not affect latency when connected.

Should I use a powered USB hub? Avoid hubs for latency-sensitive audio. Hubs add a small amount of latency (typically 0.1-0.3 ms) and can introduce jitter. Connect your audio interface directly to a motherboard USB port.

Why not test at quantum 64? Several interfaces on this list are unreliable at quantum 64 on this system. A leaderboard with half the entries marked "unstable" is not useful. Quantum 128 is the lowest practical setting for most USB interfaces in 2026. See the quantum selection guide for finding your own threshold.

My interface is not on the list. Can I submit measurements? Follow the method above and compare your fixed overhead numbers. If your measurement methodology matches, the results should be comparable.

Do Thunderbolt interfaces have lower latency? Yes, typically 0.5-1 ms lower fixed overhead than USB because Thunderbolt avoids the USB isochronous transfer overhead. But Thunderbolt interfaces on Linux have limited support and the driver situation is more complex. That is a separate discussion.

Conclusion

The RTL spread across ten USB audio interfaces at quantum 128 is 6.8 to 9.1 ms. That is a 2.3 ms range. The RME leads, the Behringer trails, and everything else clusters in between. For selecting an interface for Linux audio work, the latency differences are real but small. Pick your interface based on features, preamp quality, and channel count first. If you need the absolute lowest latency, the fixed overhead numbers here tell you which interfaces give you the most headroom at aggressive quantum values.