You plug in your audio interface and the latency meter refuses to drop
You connect your USB sound card, launch your digital audio workstation, and the latency readout sits at 150 milliseconds. You try to record a vocal track, and the playback stutters. The application prints a buffer underrun warning and refuses to start the audio engine. You have the hardware and the software, but the Linux audio stack is routing your signals through a chain of compatibility layers that were never designed for professional recording.
What is actually happening
Modern Fedora ships with PipeWire as the default audio server. PipeWire replaces the old two-daemon setup where PulseAudio handled desktop sound and JACK handled professional audio. Instead of maintaining separate routing tables, PipeWire uses a single graph-based scheduler. It treats every audio stream as a node in a directed graph. Desktop applications like web browsers and media players connect to the PulseAudio compatibility layer. Professional applications connect to the JACK compatibility layer or directly to PipeWire. The scheduler prioritizes low-latency streams and dynamically adjusts buffer sizes based on system load.
Think of it like a highway system. PulseAudio was a local road network optimized for comfort. JACK was a dedicated freight corridor optimized for speed. They required expensive interchanges to talk to each other. PipeWire builds a single multi-lane highway with dynamic lane assignment. Emergency vehicles get priority lanes. Regular traffic stays in the outer lanes. The traffic control system adjusts the speed limits automatically.
The catch is that PipeWire does not expose its configuration through a graphical settings panel. You interact with it through command-line tools and DAW preferences. If your DAW expects JACK, you need the bridge package. If your DAW expects PulseAudio, you need the compatibility layer. If your DAW supports PipeWire natively, you skip the middlemen entirely.
Reboot before you debug. Half the time the symptom is gone.
The fix
Start by installing your digital audio workstation and the PipeWire compatibility packages. Fedora splits the audio stack into modular components so you only pull in what you actually need.
sudo dnf install ardour pipewire pipewire-pulse pipewire-jack
# ardour is the DAW example. Replace with your actual package name.
# pipewire-pulse provides the PulseAudio compatibility layer for desktop apps.
# pipewire-jack provides the JACK API bridge for legacy professional software.
After the packages install, you need to restart the user-level audio services. PipeWire runs as a user service, not a system daemon. This means it starts when you log in and stops when you log out. System-level restart commands will fail because the service belongs to your user session.
systemctl --user restart pipewire pipewire-pulse pipewire-jack
# The --user flag targets your login session instead of the system-wide init.
# Restarting all three ensures the graph rebuilds with the new bridges active.
# PipeWire will automatically reload its configuration files from ~/.config/pipewire/.
If you are using a USB audio interface, unplug it and plug it back in after the restart. The kernel will re-enumerate the device and PipeWire will create a fresh node in the routing graph. This prevents stale device references from blocking your new configuration.
Trust the package manager. Manual file edits drift, snapshots stay.
Configure latency and sample rate
Buffer size determines latency. A buffer of 1024 samples at 48 kHz gives you roughly 21 milliseconds of latency. A buffer of 128 samples gives you roughly 2.6 milliseconds. Professional recording requires the smaller buffer. Desktop playback requires the larger buffer to survive CPU spikes. PipeWire handles this by running two separate contexts: one for low-latency professional streams and one for standard desktop streams.
You need to tell PipeWire which sample rate your hardware supports. Most audio interfaces lock to 44.1 kHz or 48 kHz. If your DAW requests 48 kHz but your interface is stuck at 44.1 kHz, the audio will crackle or drop out entirely. PipeWire delegates hardware policy to WirePlumber, the session manager that sits between PipeWire and the kernel.
Create a WirePlumber configuration override to lock your interface to a fixed sample rate.
mkdir -p ~/.config/wireplumber/main.lua.d
# WirePlumber reads Lua configuration files from this user directory.
# The main.lua.d folder allows you to drop in custom policy scripts.
# Files here override the system defaults without touching /usr/lib/.
Create a file named 99-hardware-policy.lua inside that directory. Add the following lines.
-- This script sets a fixed sample rate for your audio interface.
-- Replace "Focusrite Scarlett" with your actual device name.
-- WirePlumber applies this policy before PipeWire builds the routing graph.
table.insert(alsa_monitor.properties, {
["alsa.name"] = "Focusrite Scarlett",
["api.alsa.rate"] = "48000",
["api.alsa.period-size"] = "128",
})
-- api.alsa.rate locks the hardware clock to 48 kHz.
-- api.alsa.period-size sets the default buffer size for low-latency mode.
-- WirePlumber will refuse to switch rates unless explicitly overridden.
Reload the session manager and restart the audio stack.
systemctl --user restart wireplumber pipewire pipewire-pulse pipewire-jack
# wireplumber must restart to parse the new Lua policy file.
# Restarting PipeWire forces it to rebuild the graph with the locked rate.
# The changes persist across reboots because they live in your home directory.
Run pw-cli info all | grep -i "rate\|buffer" to verify the hardware node is reporting the correct values. The rate should match your Lua configuration. The buffer size should reflect your period-size setting.
Snapshot the system before the upgrade. Future-you will thank you.
Verify it worked
Open a terminal and query the active audio server. The pactl command talks to the PulseAudio compatibility layer, which PipeWire exposes by default.
pactl info | grep "Server Name"
# pactl queries the PulseAudio socket.
# PipeWire intercepts this request and returns its own identifier.
# The output should read PipeWire, not PulseAudio.
If the output shows PulseAudio, the compatibility layer failed to start. Check your user journal for initialization errors. If it shows PipeWire, the routing graph is active. Open your DAW and set the audio driver to JACK or PipeWire. Set the buffer size to 128 or 256 samples. Start playback. The latency should drop below 10 milliseconds.
Run pw-cli info all | grep -i "name\|state" to inspect the active graph nodes. You will see your audio interface listed as an active source and sink. The state field should read running. If it says suspended, PipeWire is waiting for an application to request the stream.
Run journalctl first. Read the actual error before guessing.
Common pitfalls and what the error looks like
The most common failure mode is a real-time scheduling limit. Professional audio requires the kernel to prioritize audio threads over background tasks. Fedora enforces a default limit on how many real-time threads a user can create. When you hit that limit, your DAW crashes with a permission error.
JACK: Cannot append client, port registration failed.
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
The first line means PipeWire cannot allocate a real-time thread for the JACK bridge. The second line means your DAW is trying to access an ALSA device that PipeWire has already claimed. Fix the thread limit by editing the systemd user configuration.
mkdir -p ~/.config/systemd/user
# Create the user-level systemd override directory if it does not exist.
# Systemd reads drop-in files from here before applying defaults.
Create a file named pipewire.service.d/limits.conf inside that directory. Add the following lines.
[Service]
LimitRTPRIO=99
LimitRTTIME=infinity
# LimitRTPRIO raises the maximum real-time priority from the default 0 to 99.
# LimitRTTIME removes the artificial cap on how long a real-time thread can run.
# These values match the requirements for professional audio scheduling.
Reload the user manager and restart the services.
systemctl --user daemon-reload
systemctl --user restart pipewire pipewire-pulse pipewire-jack
# daemon-reload forces systemd to parse the new drop-in configuration.
# Restarting applies the new limits to the running audio daemons.
# The changes persist across reboots because they live in your home directory.
Another frequent issue is device naming conflicts. If you have multiple audio interfaces, ALSA assigns them numeric IDs that change when you unplug a device. Your DAW configuration might reference hw:1 today and hw:2 tomorrow. PipeWire solves this by using persistent device names, but legacy JACK applications still read ALSA IDs. Use alsamixer or aplay -l to find the stable card name, then create an ALSA configuration file that maps a fixed name to your interface.
SELinux denials also surface when third-party DAWs try to access raw audio devices. Fedora ships with SELinux in enforcing mode by default. If your DAW fails to start, check the audit log before disabling the security module.
journalctl -t setroubleshoot | tail -n 20
# The setroubleshoot service translates raw AVC denials into readable summaries.
# Look for lines mentioning your DAW executable and /dev/snd/.
# The output will suggest a restorecon command or a policy module to install.
If the boot menu is gone, GRUB rescue is your friend, not your enemy.
When to use this vs alternatives
Use PipeWire when you want a single audio server that handles desktop playback and professional recording without manual routing. Use legacy JACK when you are running a decade-old plugin that only compiles against the JACK 1.9 API and refuses to load on newer libraries. Use direct ALSA when you are writing a kernel module or a bare-metal audio driver that bypasses userspace entirely. Stay on the default Fedora configuration if you only record occasionally and do not need sub-millisecond latency.