Linux DJ

Linux Audio Quality: A Practical Tuning Guide

Linux audio quality is not a single knob you turn. It is a chain of decisions that starts at the hardware interface, passes through kernel drivers and a sound server, and ends at whatever your monitors or headphones can actually reproduce. In this guide I walk through ALSA, JACK, and PipeWire roles, explain where sample rate and buffer size choices actually matter, dig into what causes XRUNs and what does not, and cover MIDI timing, USB interface behavior, resampling traps, and a practical troubleshooting order that saves hours. These are notes from over a decade of running tracking sessions, live sets, and benchmark sweeps on Linux, distilled into the things that move the needle rather than the things that fill forums. For broader context on the Linux audio community and developer resources, see the Linux Audio Developers and Users hub.

How ALSA, JACK, and PipeWire Divide the Work

Think of your Linux audio stack as three layers of a postal system. ALSA is the mailbox nailed to the wall - it is the kernel-level interface that talks directly to your sound hardware. Every byte of audio on a Linux machine passes through ALSA at some point, whether you realise it or not. ALSA handles device enumeration, PCM streams, mixer controls, and hardware parameter negotiation. It is fast and minimal, but it has no opinion about how multiple applications should share the hardware.

That is where the sound server layer comes in. JACK was built specifically for professional audio work. It provides sample-accurate routing between applications, enforces a single sample rate and buffer size across all connected clients, and runs with real-time scheduling priority when the system allows it. JACK does not try to be friendly to casual desktop audio. It assumes you know what you want and gives you the wiring to get there.

PipeWire arrived later with a broader mandate: replace PulseAudio for desktop audio, provide a JACK compatibility layer, handle video streams, and do all of it with lower latency than PulseAudio ever managed. In practice, PipeWire has become the default on most major distributions since 2022. Its JACK compatibility mode works well for many workflows, but it is not identical to standalone JACK. The session manager, the graph latency accounting, and certain edge cases around MIDI clock behave differently. If you are doing critical tracking or live performance, test both and measure. Do not assume.

For most desktop production work in 2026, PipeWire with WirePlumber is the sensible default. For dedicated low-latency recording rigs where every microsecond matters, standalone JACK with a tuned kernel still has the edge. Both talk to ALSA underneath. The quality ceiling is the same. The difference is in scheduling discipline and failure modes.

Sample Rate: What You Gain and What You Waste

The short version: 44.1 kHz or 48 kHz is sufficient for the vast majority of work. Running at 96 kHz doubles your CPU and bus overhead for content above 22 kHz that your monitors almost certainly cannot reproduce faithfully and your ears cannot hear. There are legitimate reasons to record at higher rates - headroom for pitch manipulation, certain plugin algorithms that benefit from oversampling at the source, archival preference - but these are specific, considered choices, not defaults.

The real trap is mixing sample rates without realising it. If your interface is locked at 48 kHz and a session file is 44.1 kHz, something has to resample. If that something is a lazy automatic conversion you did not configure, you get artifacts. Worse, you might not hear them on small monitors and only discover the problem on a proper system months later. Pick a rate for the project, set it at the ALSA device level, confirm the sound server agrees, and leave it alone.

One wrinkle worth knowing: some USB interfaces handle 44.1 kHz and 48 kHz with different internal clock paths. Certain Focusrite and Behringer devices, for instance, produce measurably lower jitter at 48 kHz because of how their clock dividers are wired internally. If you care enough to measure, measure. If not, pick 48 kHz and move on.

Buffer Size: The Latency and Stability Lever

Buffer size is the single most misunderstood setting in Linux audio. A buffer is a chunk of samples the system accumulates before handing it to the next stage. Smaller buffers mean less delay between input and output. Larger buffers mean more breathing room for the CPU and fewer chances of a dropout.

At 48 kHz with a buffer of 256 samples and two periods, your theoretical round-trip latency is around 10.7 milliseconds. That is fine for tracking vocals or guitar. Drop to 64 samples and you are under 3 ms, which feels essentially instantaneous, but your system has to fill that buffer every 1.3 ms without fail. One stall from a USB hub, a filesystem flush, or a misbehaving background process and you get an XRUN.

The practical approach: start at 256 or 512 samples. Record. Lower the buffer only if the latency is actually bothering the performer. Many experienced engineers record at 256 and never think about it. Monitoring through hardware direct monitoring removes the round-trip from the performer's experience entirely, which makes the buffer size debate moot for tracking and only relevant for live processing. For deeper latency measurement approaches, see the low-latency resources page and the latency graphing tool.

XRUNs: What Actually Causes Them

An XRUN happens when the audio buffer runs dry (underrun) or overflows (overrun) because the system could not keep up. The result is a click, a pop, or a gap in the audio stream. JACK and PipeWire both report XRUNs. ALSA will silently insert zeros, which is arguably worse because you might not notice until playback.

Common causes, in rough order of how often I see them in practice:

  1. USB bandwidth contention. A hub shared with a webcam, a keyboard with RGB polling at 1000 Hz, or a bus-powered drive doing writes. Move the audio interface to its own root USB controller if possible.
  2. CPU frequency scaling. Power governors that drop the clock mid-buffer are an instant XRUN source. Set the governor to performance during sessions, or use cpupower to lock a minimum frequency.
  3. Filesystem flushes. Large writes to spinning disks, or even NVMe drives during certain firmware maintenance windows, can stall the kernel long enough to miss a deadline. Use a dedicated audio partition or tmpfs for scratch when latency is critical.
  4. IRQ routing and affinity. On multi-core systems, pinning the audio interface IRQ to a specific core and keeping that core free of other heavy interrupts can reduce worst-case latency significantly. This matters more at very low buffer sizes.
  5. Kernel and scheduler. A stock kernel with voluntary preemption handles most studio work. PREEMPT_RT helps at the margins, below 128 samples. The HDRBench tool is useful for profiling how your specific kernel and hardware combination behaves under load.

Not a common cause, despite what forums suggest: RAM amount. Unless you are running so low that the system is swapping, adding more RAM will not fix XRUNs. The bottleneck is almost always timing, not capacity.

MIDI Timing on Linux

MIDI timing on Linux is better than its reputation. ALSA sequencer provides high-resolution timestamping. JACK MIDI ties MIDI events to the audio graph cycle, which gives you sample-accurate placement. PipeWire's MIDI handling has improved substantially, but edge cases around clock drift on long sessions still surface in some configurations.

The most common MIDI timing problem I encounter is not the stack. It is USB MIDI adapters with poor firmware. Cheap adapters with no brand name and a generic USB ID often buffer internally in unpredictable ways, adding 3 to 15 ms of jitter that no amount of software tuning can fix. If your MIDI timing feels sloppy, swap the cable before you start recompiling kernels.

For hardware synths clocked via MIDI, the USB polling interval matters. The default 10 ms USB polling on some configurations is enough to make a drum machine feel sluggish. Reducing the polling interval to 1 ms (via the snd-usb-audio module parameter or udev rules) tightens things up noticeably. Just be aware that faster polling increases CPU overhead slightly, which is fine on modern hardware but relevant on embedded systems.

USB Interface Quirks

USB audio interfaces on Linux range from flawless to adversarial, and the price tag is not a reliable indicator. The ALSA driver for USB audio (snd-usb-audio) is a class-compliant driver, which means any USB Audio Class 2.0 device should work without proprietary drivers. In practice, most do. The exceptions are devices that rely on vendor-specific extensions for features like internal mixing, DSP routing, or firmware-based monitoring.

Devices I have found consistently reliable on Linux over the years: anything from RME (Babyface, UCX, Fireface UC), MOTU interfaces with USB Audio Class 2 support, and Focusrite Scarlett units from the second generation onward. Behringer UMC series works at the basic level but occasionally exhibits clock drift at 44.1 kHz. PreSonus devices are generally fine, though some models need a firmware version that enables class compliance.

One practical tip: if an interface works at 48 kHz but produces clicks at 44.1 kHz (or vice versa), the issue is almost always the internal clock source, not the Linux driver. Try toggling between internal and external clock, and check whether the device has a firmware update that addresses sample rate switching behavior.

Resampling and Monitoring Pitfalls

Resampling in the digital audio path is sometimes necessary and sometimes invisible. PulseAudio resampled aggressively and silently, often at mediocre quality, which gave Linux audio a bad reputation in audiophile circles. PipeWire improved the default resampler and made the quality setting configurable, but the fundamental problem remains: if two applications want different sample rates, something has to convert.

The cleanest solution is to avoid resampling entirely. Set your hardware to one rate. Set your sound server to match. Work in that rate. If you must resample, use a quality setting of at least SPA_PROP_quality=8 in PipeWire, or an equivalent high-quality resampler like libsamplerate at best quality. The CPU cost of good resampling is trivial on modern hardware, so there is no reason to accept a poor algorithm.

Monitoring is the other blind spot. If you are mixing on consumer-grade speakers or laptop speakers, you will not hear resampling artifacts, low-frequency phase issues, or subtle distortion from misconfigured bit depths. You do not need expensive monitors, but you need honest ones. A pair of flat-response nearfields and a decent headphone amplifier reveal problems that no amount of metering can replace. Trust your tools, then trust your ears. In that order.

The Measurement Mindset

The single biggest shift that separates productive Linux audio work from endless forum-driven tweaking is this: measure before you change, measure after, and keep notes. Not mental notes. Actual notes. A text file. A spreadsheet. A notebook next to the keyboard. Whatever works.

Run jack_iodelay or the PipeWire equivalent to measure real round-trip latency. Run HDRBench or cyclictest to profile scheduling behavior under load. Record 60 seconds of silence and look at the noise floor in a spectrogram. These take minutes and save days.

The temptation is always to change three things at once: new kernel, new buffer size, new USB port. Then when it works (or breaks), you have no idea which change mattered. Change one variable. Test. Record the result. Move to the next variable. This is not exciting. It is effective.

For structured profiling approaches and tools, the HDRBench page covers timer-resolution benchmarking and the Latency Graph tool helps visualize scheduling traces across different kernel configurations.

Practical Troubleshooting Order

When something sounds wrong or unstable, resist the urge to start with kernel patches. Start with the boring stuff. Here is the order I follow after years of doing this:

  1. Check cables and physical connections. Loose XLR, damaged TRS, or a USB cable that has gone intermittent. This accounts for more "mysterious" problems than anyone likes to admit.
  2. Confirm sample rate agreement. Interface, sound server, and application must all match. Use cat /proc/asound/card*/pcm*/sub*/hw_params to see what the hardware is actually running.
  3. Check for mixed bit depths. Running a 16-bit stream into a 24-bit pipeline (or the reverse) can introduce quantisation noise or unexpected headroom behavior.
  4. Monitor XRUN counts. In JACK, the counter is in the top bar. In PipeWire, use pw-top to watch for dropouts in real time.
  5. Isolate the USB bus. Move the audio interface off shared hubs. Check lsusb -t to see what shares a controller.
  6. Set the CPU governor. Switch to performance during sessions.
  7. Check IRQ affinity and priorities. Use rtirq or manual chrt adjustment if needed.
  8. Then consider kernel changes. Only after everything above checks out should you look at PREEMPT_RT, threadirqs, or custom scheduling parameters. Consult the low-latency resources for kernel-level tuning details.

Most problems resolve at step 1 through 5. The last three steps matter for competitive latency targets, not for general quality and stability. If your audio sounds bad at 256 samples, a real-time kernel will not fix it. Something earlier in the chain is wrong.

Closing Notes

Linux audio in 2026 is genuinely good. PipeWire has brought sanity to the desktop. JACK remains rock-solid for dedicated work. ALSA continues to gain device support. The tools for measuring, profiling, and debugging are better than they have ever been. The gap between Linux and proprietary platforms for production audio is narrower than most people assume, and for certain workflows - networked audio, headless recording, custom DSP pipelines - Linux is the better choice by a wide margin.

What separates a Linux audio setup that works from one that frustrates is not the distribution, the desktop environment, or the brand of interface. It is whether someone took the time to understand the signal chain, measure the behavior, and make deliberate choices instead of copying forum posts. That is what this guide is for. Measure, configure, verify. Then make music.

For community discussion, technical resources, and links to mailing lists and developer notes, continue to the Linux Audio Developers and Users hub.