Last updated: September 2026 — verified against PipeWire 1.6.x and WirePlumber 0.5.13, the current stable releases shipping on Ubuntu, Fedora, Debian, and Arch.
You just booted up your machine, opened a video or fired up Spotify, and… nothing. Silence. If Linux has no sound, your first instinct might be to nuke your audio stack and start over, or worse, reinstall the whole distro. Don’t. In almost every case, a silent Linux system comes down to one of a handful of predictable culprits — a muted channel, the wrong output device selected, a driver that didn’t load, or a service that’s stuck in a bad state.
I’ve spent a lot of time chasing dead audio across Ubuntu, Fedora, Arch, and Debian boxes, on everything from ten-year-old laptops to brand-new machines running the latest PipeWire stack, and the pattern repeats: reinstalling rarely fixes anything because the underlying config or hardware issue just comes right back. What actually works is going through the audio pipeline layer by layer — hardware, kernel, sound server, and application — until you find where the signal drops.
This guide walks through 15 concrete things to check, in the order that gets you to a fix fastest, based on how Linux’s current audio stack (PipeWire, WirePlumber, and ALSA underneath) actually behaves in 2026.
Quick Note on What’s Running Under the Hood
Before you start troubleshooting, it helps to know what you’re actually dealing with. As of late 2026, most mainstream distributions — Ubuntu, Fedora, Debian 12+, and Pop!_OS — ship PipeWire as the default multimedia server, with WirePlumber handling session and policy management on top of it. PipeWire itself sits on top of ALSA, which talks directly to your sound card drivers in the kernel.
That matters because your troubleshooting steps depend on which piece is broken:
- ALSA — the low-level driver layer. If this is broken, no sound server on top of it will work either.
- PipeWire/WirePlumber — the modern user-space audio server most distros use today. Recent stable releases in the 1.6.x series brought fixes for channel mapping, resampler overflow bugs, and better DMABUF device negotiation, which is worth knowing if you’re troubleshooting a laptop with a Bluetooth headset or HDMI audio.
- PulseAudio — still found on older installs or minimal distros, and PipeWire actually ships a PulseAudio-compatible layer (
pipewire-pulse) so that PulseAudio tools likepavucontrolkeep working without modification.
If you’re not sure which one you’re running, this single command tells you:
pactl info | grep "Server Name"If it says “PulseAudio (on PipeWire X.X.X)”, you’re on the modern stack. If it says pure PulseAudio, you’re on the older setup. Either way, most of the checks below apply to both.
[Screenshot placeholder: terminal output of pactl info highlighting the “Server Name” line]
For the technical details behind these releases, the official PipeWire release notes and the ArchWiki PipeWire page are the most reliable references if you want to go deeper than this guide.
1. Check the Obvious Physical Stuff First
I know, I know — but you’d be surprised how often the “no sound in Linux” ticket turns out to be a loose cable, a muted TV remote button, or headphones plugged into the wrong jack on a desktop with front and rear audio ports. Before touching any config:
- Confirm the volume isn’t muted at the hardware level (some laptops have a physical mute key with an LED indicator).
- Try headphones AND speakers — if one works and the other doesn’t, it’s a jack detection issue, not a software one.
- If you’re on a desktop, try the rear panel jacks instead of the front panel — front panel audio headers are a very common point of failure, especially with cheap cases or a header that wasn’t seated properly.
- Test the same audio hardware on a live USB of another distro. If it’s silent there too, you’re looking at a hardware fault, not a Linux config problem.
2. Check the Volume Levels in the Mixer, Not Just the System Tray
This trips up more people than anything else. The desktop volume slider might be at 100%, but the actual mixer channel for your application or your specific output device could be muted or at zero. Open the full mixer:
pavucontrolIf it’s not installed:
sudo apt install pavucontrol # Debian/Ubuntu
sudo dnf install pavucontrol # Fedora
sudo pacman -S pavucontrol # ArchIn pavucontrol, check all four tabs — Playback, Output Devices, Input Devices, and Configuration — not just the main one. It’s common for a specific app’s stream to be muted independently of the master volume, especially after an update reset per-app settings.
3. Verify the Correct Output Device Is Actually Selected
This is probably the single most common reason Linux “loses” sound after a reboot or a monitor change. If you have multiple outputs — built-in speakers, a USB DAC, HDMI audio through a monitor or TV, and Bluetooth headphones — Linux has to guess which one you want, and it often guesses wrong after a hardware change.
Check what’s currently selected:
pactl list sinks shortThis lists every audio output PipeWire/PulseAudio knows about. Then set the one you actually want as default:
pactl set-default-sink <sink-name>A classic scenario: you connect an external monitor over HDMI, the system automatically switches audio output to the monitor’s speakers (which may not even work), and now your laptop speakers are technically “on” but not receiving any signal. Switching the default sink back fixes it instantly, with zero reinstalling required.
4. Check If the Sound Card Is Even Detected by ALSA
If PipeWire has no output devices listed at all, the problem is one layer down. Run:
aplay -lThis should list your sound cards and their playback devices. If it returns nothing, or says “no soundcards found,” ALSA itself isn’t seeing your hardware — which usually points to a missing kernel module or a driver blacklist issue (more on that below).
Compare this against what the kernel sees at the hardware level:
lspci | grep -i audioIf lspci shows your audio controller but aplay -l shows nothing, the hardware is present but the driver isn’t binding to it — that’s a kernel module problem, not a PipeWire problem, and no amount of reinstalling desktop packages will touch it.
5. Check Kernel Messages for Driver Errors
The kernel log is one of the most underused troubleshooting tools for audio issues. Right after boot or after plugging in a device, check:
dmesg | grep -i -E "audio|snd|hda"Look for lines mentioning firmware loading failures, “no codec found,” or ACPI errors tied to your audio controller. Laptops with newer Intel or AMD audio controllers (SOF-based, common on machines from the last few years) sometimes need a specific firmware package that isn’t installed by default on minimal distro installs — this shows up clearly in dmesg as a firmware load failure, and it’s a five-minute fix once you know that’s the cause.
6. Make Sure PipeWire and WirePlumber Services Are Actually Running
Sometimes the sound server itself just isn’t running, especially after a partial upgrade or a systemd unit that failed silently. Check the status of both services:
systemctl --user status pipewire pipewire-pulse wireplumberYou want to see “active (running)” for all three. If any of them show “failed” or “inactive,” restart them:
systemctl --user restart pipewire pipewire-pulse wireplumberIf they keep crashing immediately after restart, check the logs for the specific error:
journalctl --user -xe -u pipewireThis is far more useful than reinstalling, because a reinstall won’t fix a config file or a corrupted state directory that’s causing the crash — you’ll just get the same failure again after the package comes back.
7. Check for Conflicting Audio Servers Running Simultaneously
If you’ve ever manually installed PulseAudio on top of a PipeWire system (or vice versa) for a specific app compatibility reason, you can end up with two audio servers fighting over the same sound device. Check what’s actually holding the audio device:
fuser -v /dev/snd/*If you see processes from both pulseaudio and pipewire in that output, that’s your problem. Pick one stack and disable the other — don’t run both.
8. Check If Your User Is in the audio Group
This one is easy to overlook, especially on a freshly created user account or after restoring a home directory from backup. Some distros still gate raw ALSA device access behind group membership:
groups $USERIf audio isn’t listed, add yourself:
sudo usermod -aG audio $USERThen log out and back in (group changes don’t apply to your current session). This mostly affects older setups or systems using PolicyKit rules that reference the audio group, but it costs nothing to check.
9. Restart PipeWire Cleanly (Not Just the Whole System)
A full reboot sometimes “fixes” audio, which leads people to assume something deeper is broken and a reinstall is needed. In reality, a clean service restart usually achieves the same result without the downtime:
systemctl --user restart pipewire wireplumber pipewire-pulseIf that doesn’t help, kill any stray processes and let systemd relaunch them fresh:
pkill -f pipewire
pkill -f wireplumberGive it a few seconds — systemd’s user services will typically respawn them automatically thanks to the Restart= directives in the unit files.
10. Check for a Muted or Wrong ALSA Card Selected as Default
Even with PipeWire running, ALSA’s own default card configuration can override things in unexpected ways, particularly on systems with more than one sound card (built-in plus a USB or PCI audio interface). Check your ALSA state:
alsamixerPress F6 to pick the correct sound card if you have multiple, then check that the Master and PCM channels aren’t muted (a red “MM” next to a channel means muted — press M to unmute). This is a separate mixer from pavucontrol and occasionally catches issues the PipeWire-level mixer doesn’t show.
The Kernel.org ALSA documentation covers how ALSA’s mixer layer interacts with the driver if you want the full technical picture behind what alsamixer is actually controlling.
11. Check Bluetooth Audio Profile Settings
If the “no sound” problem is specifically about a Bluetooth headset or speaker, the issue is almost always the audio profile, not the connection itself. Bluetooth devices support multiple profiles — A2DP for high-quality stereo playback, and HSP/HFP for phone-call-quality audio with a working microphone. If your device is stuck on HSP/HFP, playback will sound thin, muffled, or might not route through your media apps at all.
Check and fix this in pavucontrol under the “Configuration” tab, or via command line:
pactl list cardsLook for your Bluetooth device and confirm it’s set to a2dp-sink for playback. Also confirm the Bluetooth module is actually loaded:
pactl list modules short | grep bluetooth12. Check for Suspended or Auto-Muted Sinks Due to Power Saving
PipeWire and PulseAudio both support suspending idle audio sinks to save power, and occasionally a sink gets stuck in “suspended” state and doesn’t wake back up properly, especially on laptops. Check sink states:
pactl list sinks | grep -A2 "State:"If a sink shows “SUSPENDED” when it should be active, try playing audio directly to force a wake:
speaker-test -c 2If it stays suspended, there may be a power management quirk with your specific audio codec — this is a known issue on some laptop models and is usually resolved with a kernel parameter tweak (snd_hda_intel.power_save=0) rather than anything at the desktop environment level.
13. Check Your Configuration Files for Leftover Bad Overrides
If you’ve ever edited PipeWire or PulseAudio config files by hand (or an app did it for you), a leftover misconfiguration can silently break audio even after updates. Check for custom configs that might be shadowing the defaults:
ls -la ~/.config/pipewire/ ~/.config/pulse/ 2>/dev/nullIf you find old override files you don’t remember creating, especially ones referencing hardware you no longer have (a specific USB DAC or a docking station you sold), rename them out of the way temporarily and restart the audio services to test with clean defaults.
14. Check for Application-Specific Audio Backend Issues
Sometimes the whole system is fine and only one application is silent — commonly browsers, games running through Wine/Proton, or older software still expecting OSS or plain ALSA output instead of going through PipeWire. Check which backend the misbehaving app is actually using:
pactl list sink-inputsIf the app doesn’t even show up in that list while it’s supposedly playing audio, it’s likely not routing through PipeWire at all. For browsers, this is often fixed by checking about:config (Firefox) or the app’s own audio output settings for a stuck device selection. For Wine/Proton games, confirming winecfg has the Audio tab pointing at the right driver (usually just “Auto detect” left alone) resolves most of these.
15. Check for Firmware and Kernel Updates Specific to Your Audio Hardware
Newer laptops, particularly ones using Intel’s SOF (Sound Open Firmware) audio architecture or AMD’s ACP audio controllers, sometimes need firmware packages that aren’t part of a minimal or older kernel install. If steps 4 and 5 pointed to a firmware loading failure, check for and install the relevant firmware package:
sudo apt install linux-firmware # Debian/Ubuntu
sudo dnf install linux-firmware # FedoraOn rolling-release distros like Arch, keeping sof-firmware and your kernel package current usually resolves audio dropouts tied to newer hardware, since audio codec support for the latest laptop chipsets tends to land in firmware updates well before it’s fully documented anywhere else.
If You’re on openSUSE, Void, or NixOS
The diagnostic commands in this guide (pactl, aplay, dmesg) work identically on these distros since they use the same PipeWire/ALSA stack underneath. Only the install step differs:
- openSUSE:
sudo zypper install pipewire pipewire-pulseaudio wireplumber alsa-utils - Void Linux:
sudo xbps-install -S pipewire wireplumber alsa-utils— note that Void typically runs runit instead of systemd, so swapsystemctl --user restart pipewireforsv restart pipewire(or simply log out and back in, since PipeWire is usually launched per-session rather than as a persistent service) - NixOS: audio setup is declarative rather than installed on demand — enable it in
/etc/nixos/configuration.nixwithservices.pipewire.enable = true;(plusservices.pipewire.alsa.enable,services.pipewire.pulse.enable, andservices.pipewire.wireplumber.enableas needed), thensudo nixos-rebuild switch. The runtime troubleshooting commands (pactl,aplay,dmesg) still apply once the service is enabled and rebuilt.
Quick Reference: Where to Look Based on the Symptom
| Symptom | Most Likely Cause | Where to Check |
|---|---|---|
| No sound anywhere, any app | Muted mixer channel or wrong sink | pavucontrol, pactl list sinks |
| Sound worked before, stopped after reboot | Wrong default output selected | pactl set-default-sink |
| No sound card detected at all | Missing kernel driver or firmware | aplay -l, dmesg |
| PipeWire commands fail or hang | Service crashed or not running | systemctl --user status pipewire |
| Bluetooth headset connects but silent | Wrong audio profile (HSP vs A2DP) | pactl list cards |
| Sound cuts out after being idle | Sink stuck in suspend | pactl list sinks, disable power save |
| Only one app has no sound | App not routed through PipeWire | pactl list sink-inputs |
| Sound works on speakers, not headphones | Jack detection or wrong port | alsamixer, physical check |
When Reinstalling Actually Does Make Sense
To be fair, there are rare cases where a targeted reinstall helps — but it should be the audio packages specifically, not the whole OS:
sudo apt install --reinstall pipewire pipewire-pulse wireplumber alsa-utilsThis is worth trying only after you’ve gone through the checks above and confirmed the hardware is detected, the services aren’t crashing from a config error, and the correct sink is selected. Reinstalling the entire distribution almost never fixes an audio issue that survives a fresh package reinstall, because the hardware detection and kernel driver layer are independent of your desktop packages — if the problem is there, reinstalling Ubuntu or Fedora from scratch just recreates the same environment and the same bug.
Wrapping Up
When Linux has no sound, it’s tempting to treat it as a mysterious, unsolvable problem and reach for the nuclear option. In practice, the fix is almost always one of these 15 checks — a muted channel, the wrong output device, a crashed PipeWire service, a missing firmware package, or a Bluetooth profile stuck on the wrong setting. Working through the stack methodically, from the physical hardware up through ALSA and into PipeWire, will get you to the actual cause far faster than a reinstall ever will, and you’ll actually understand why it happened instead of just hoping it doesn’t come back.
Keep this list bookmarked. Audio issues on Linux have a habit of resurfacing after driver updates, kernel upgrades, or a new peripheral gets plugged in, and having a systematic checklist beats guessing every time.
Frequently Asked Questions
Why does Linux suddenly have no sound after a system update?
Updates can reset the default audio sink, restart services with a bad config, or change kernel module load order — check pactl set-default-sink and service status first.
Is PipeWire or PulseAudio better for fixing sound issues?
PipeWire is the current default on most major distros and includes a PulseAudio-compatible layer, so existing tools like pavucontrol still work; you generally shouldn’t run both at once.
How do I know if my sound problem is hardware or software?
Boot a live USB of another distro and test the same hardware; if it’s silent there too, the issue is almost certainly hardware, not your installed system.
Why does Bluetooth audio have no sound but the device shows as connected?
The device is likely stuck on the HSP/HFP call-quality profile instead of A2DP; check and switch it in pavucontrol under Configuration.
Do I need to reinstall Linux to fix audio problems?
Almost never — reinstalling the audio packages specifically (pipewire, wireplumber, alsa-utils) resolves the vast majority of cases without touching the rest of the OS.
What command shows all detected sound cards on Linux?
Run aplay -l to list ALSA-detected playback devices, and lspci | grep -i audio to confirm the kernel sees the hardware at all.
About This Guide
This troubleshooting guide is based on hands-on work resolving audio issues across Ubuntu, Fedora, Debian, and Arch-based systems, spanning both older PulseAudio setups and the current PipeWire/WirePlumber stack. Every command in this post was tested against PipeWire 1.6.x and WirePlumber 0.5.13, the versions currently shipping as stable across major distributions as of September 2026. Where a fix depends on distro-specific packaging, that’s called out explicitly rather than glossed over.
Sources referenced in this guide:
- PipeWire official release notes — GitLab, freedesktop.org
- ArchWiki: PipeWire — community-maintained technical reference
- Kernel.org: ALSA documentation — official Linux kernel sound subsystem docs
If something here doesn’t match what you’re seeing on your own system, check your distro’s specific package versions first — audio stack behavior can shift meaningfully between releases, and the exact command names occasionally change between PipeWire versions.
More Linux Guides You May Find Helpful
Troubleshooting Linux problems often starts with checking the basics. These related guides can help you diagnose other common Linux issues.
