Implementing Linux Real-Time Audio Processing for Professional Music Production

Linux audio is fast—until it isn’t

Picture this. You hit record, sing the first line, and… your voice comes back half a second later. Feels like talking on a bad Zoom call. That’s latency. On Linux it still happens, even in 2025.

I know because it happened to me last month. I was tracking vocals in Ardour. Take five. Perfect vibe. Then *crackle-crackle-pop*—the recording glitched and the magic evaporated. I spent the rest of the evening chasing dropouts instead of making music.

What latency really is (plain-English version)

Latency = the time between making a sound and hearing it.

• Below 10 ms? Feels fine on most instruments.
• Below 2 ms? You can play soft synths live without drifting off beat.
• Above 20 ms? Your drummer will throw sticks at you.

Dropouts are worse. They sound like tiny record scratches and they print straight into the take. Once they’re on the track, you need another take.

Step 1: Pick a kernel that actually cares about timing

Regular Linux treats audio like any other app. That’s the problem.

Fix: install a kernel that pre-empts normal tasks when audio asks for the CPU.

Fast ways:

• Ubuntu 24.04 already ships 6.6 with PREEMPT_RT built-in—just update.
• Fedora? Grab the kernel-rt package.
• On Arch? Run yay -S linux-rt and reboot.

After the reboot I ran:

sudo tuned-adm profile latency-performance

That single command lowered my round-trip latency from 12 ms to 6 ms without touching a config file.

Step 2: Switch to PipeWire (and forget JACK)

JACK is great. PipeWire is JACK on espresso.

Three reasons to upgrade:

1. Sub-2 ms round-trip on USB interfaces.
2. Bluetooth gear finally works with the same low latency.
3. No more “Jack server is not running” tantrums.

Quick check:

pw-top

If the ERR column stays at zero, your buffers are happy.

Step 3: Cage the CPU hogs

My browser loves hogging one core just to display cat GIFs. That core used to steal cycles from Ardour.

Fix: lock audio apps to their own CPUs.

sudo systemctl set-property --runtime -- user.slice AllowedCPUs=0-5
sudo systemctl set-property --runtime -- ardour.slice AllowedCPUs=6-7

Translation: normal apps stay on cores 0-5. Ardour and plugins get dedicated cores 6-7. No more random dropouts when Firefox decides to auto-update.

The hardware checklist no one tells you about

Even perfect software can’t fix bad hardware.

• USB-C audio interface – RME Babyface Pro FS still the king. Plug-and-play on Linux, 1 ms round-trip.
• BIOS tweaks – Disable “C-states” and “Turbo Boost” in BIOS. Yes, it uses more power. It also removes the tiny sleeps that cause xruns.
• PCIe DSP card – If you run big convolution reverbs, grab a used Lynx Aurora(n). Reverb load drops from 30 % CPU to 2 %.

When I disabled C-states on my ThinkPad, the average xrun count went from 6 per hour to zero.

Cloud trick: let AWS do the heavy lifting

Last week I mixed a track with 100-track sessions and AI stem separation. My laptop would have melted.

Instead, I launched a NetJack2 session to an AWS Graviton4 instance:

jackd -d net -a 3.91.123.45 -p 1024

My laptop only handled playback and MIDI. AWS did the rest. Latency? Still under 3 ms because the instance was in the same city.

How to know you nailed it

One command tells the whole story:

sudo bpftrace -e 'tracepoint:snd_pcm:xrun { @[comm] = count(); }'

Let it run for an hour. If the counter stays at zero, you’re golden. If it climbs, scroll back, tweak one setting at a time, and test again.

Takeaway

Linux audio in 2025 is almost plug-and-play. Almost. Spend an evening on the steps above and you’ll never lose another take to glitches. I haven’t had a single dropout since.

Your turn. Run pw-top now and post your lowest latency number in the comments. Let’s see who hits sub-1 ms first.