You upgraded Fedora and the audio sounds like a robot chewing gravel
You are on a video call. Your voice comes out distorted, or the music stutters every few seconds. You just upgraded to a newer Fedora release, or your laptop woke from sleep and the audio is broken. The system is running. The network is fine. The speakers work for system beeps. But real-time audio is unusable.
This is rarely a hardware failure. The audio server is dropping packets, or the sample rate configuration is fighting your sound card. The fix usually involves aligning the software buffer with the hardware capabilities and ensuring the audio server matches your Fedora version.
What is actually happening
Audio subsystems work by filling a buffer. Applications write audio data into this buffer. The sound server reads the data and sends it to the hardware driver. The hardware plays it at a steady rate.
If the application writes data too slowly, the buffer empties. That is an underrun. The result is silence, pops, or crackling. If the application sends audio at 44100 Hz but your hardware expects 48000 Hz, the server must resample the audio on the fly. Resampling consumes CPU cycles. If the CPU is busy or the resampler is misconfigured, the buffer empties and the audio glitches.
Think of it like a factory conveyor belt. The belt moves at a fixed speed. Workers pack boxes onto the belt. If the workers slow down, the belt runs empty. The machine jams. You need to either speed up the workers or slow down the belt.
Identify the audio server
Fedora 38 and later ship with PipeWire by default. PipeWire replaces PulseAudio and ALSA for most user-space audio tasks. It handles Bluetooth, low-latency recording, and video streams better than the legacy stack. Older releases or minimal installs may still run PulseAudio. The commands to diagnose audio are similar, but the service names and config paths differ.
Run this command to see which server is active.
pactl info | grep "Server Name"
# WHY: Queries the PulseAudio-compatible API to identify the backend.
# Output will show "PulseAudio" or "PipeWire-Pulse".
# This determines which service to restart and which config files to edit.
If the output shows PipeWire-Pulse, you are on the modern stack. Fedora users should prefer PipeWire. It resolves many crackling issues automatically by managing sample rates more aggressively. If you see PulseAudio, you may be on an older release or a custom minimal install.
Restart the service after checking. A fresh start clears stuck buffers.
systemctl --user restart pipewire.service pipewire-pulse.service
# WHY: Restarts the PipeWire daemon and its PulseAudio compatibility layer.
# The --user flag targets the user session, which is where audio runs.
# This applies immediately without a reboot.
If you are on PulseAudio, use pulseaudio -k to kill the daemon. It restarts automatically.
Restart the service before debugging. Half the time the symptom is gone after a clean restart.
Check sample rates and buffer settings
Mismatched sample rates are the most common cause of crackling. Music files often use 44100 Hz. Video streams and modern hardware prefer 48000 Hz. If the server tries to resample constantly, latency spikes and the buffer underruns.
Check the current sample rate of your active sink.
pactl list sinks short
# WHY: Lists all audio sinks and their properties in a compact format.
# Look for the sink with "RUNNING" state.
# Note the sample rate column. It should match your hardware capability.
If the sample rate fluctuates or shows a value your hardware does not support, force a fixed rate. Edit the configuration file. Never edit files in /usr/lib/. Those ship with the package and get overwritten on updates. Edit /etc/ or ~/.config/.
For PulseAudio, modify /etc/pulse/daemon.conf. For PipeWire, the settings are in ~/.config/pipewire/pipewire.conf or via wireplumber config. The example below uses PulseAudio syntax, which applies to the pipewire-pulse compatibility layer as well.
# /etc/pulse/daemon.conf
default-sample-rate = 48000
# WHY: Forces the system to use 48kHz as the base rate.
# This matches most modern sound cards and video streams.
avoid-resampling = yes
# WHY: Prevents the server from changing sample rates dynamically.
# Applications must provide audio at the correct rate, reducing CPU load.
After editing, restart the service. The server does not reload config files automatically.
systemctl --user restart pipewire-pulse.service
# WHY: Reloads the configuration changes.
# Without this, the old settings remain in memory.
Check the sample rate before blaming the hardware. Mismatched rates cause more glitches than broken speakers.
Apply the LADSPA workaround for stubborn hardware
Some sound cards reject standard sample rates or have buggy drivers. The audio server may fail to negotiate a stable rate. In these cases, a software resampler can smooth out the stream. The module-ladspa-sink with the ratectl plugin forces a software rate control that bypasses hardware quirks.
This is a workaround, not a permanent fix. Use it only when sample rate alignment fails.
Load the module with the correct parameters.
pactl unload-module module-ladspa-sink
# WHY: Removes any existing instance of the module.
# Loading it twice causes conflicts and can silence audio entirely.
pactl load-module module-ladspa-sink sink_name=fix_audio label=Fix Audio plugin=ratectl controls=0
# WHY: Loads a software resampler that handles rate conversion.
# The sink_name creates a new virtual output.
# Applications may need to be routed to this sink manually.
If the crackling stops, the issue was a hardware sample rate negotiation failure. You can make this change persistent by adding the load command to ~/.config/pulse/default.pa or the PipeWire equivalent.
Do not use this module on systems with low CPU. Software resampling adds overhead.
Verify the fix
Play a test tone or a music file. Listen for pops. Run a speaker test to check both channels.
speaker-test -t wav -c 2
# WHY: Plays a WAV tone on two channels.
# This tests the hardware path without variable bitrate codecs.
# Press Ctrl+C to stop.
If the test tone is clean but music crackles, the issue is likely an application codec or a specific file format. If the test tone crackles, the buffer or driver is still misconfigured.
Check the journal for errors. The journalctl output often reveals the root cause.
journalctl -xeu pipewire-pulse.service
# WHY: Shows recent logs for the audio service with explanatory text.
# Look for "underrun", "resampler", or "failed to set rate".
# The -x flag adds hints, and -e jumps to the end.
Run the speaker test. If the tone is clean, the audio stack is healthy.
Common pitfalls
Bluetooth audio introduces latency. The Bluetooth protocol uses different codecs than wired audio. If your audio crackles only on Bluetooth headphones, the issue is likely the codec negotiation, not the buffer. Switch to a high-quality codec in pavucontrol or check bluetoothctl settings.
High sample rate applications can break the stream. Professional audio software may request 96000 Hz or higher. If the hardware cannot handle that rate, the server may glitch. Force the application to use 48000 Hz or lower.
Editing the wrong config file causes drift. Files in /usr/lib/ are managed by the package manager. Changes there disappear on upgrade. Always edit /etc/ or user config directories.
firewall-cmd --reload is irrelevant for local audio, but if you are streaming audio over the network, ensure the firewall allows the port. Local audio issues are almost never firewall problems.
Snapshot the config before editing. A typo in the daemon config can silence the entire system.
When to use this approach
Use PipeWire when you are on Fedora 38 or newer and want lower latency with better Bluetooth support. Use PulseAudio configuration when you are on an older release or running a legacy application that requires the classic stack. Use the LADSPA rate control module when your hardware crackles specifically during sample rate changes or with certain video players. Use pavucontrol when you need to route audio to a specific output or adjust per-application volume without touching config files. Stay on the default audio stack if your system works fine. Manual tweaks introduce maintenance overhead.