No Sound on Linux? Troubleshoot PipeWire, WirePlumber, ALSA & Bluetooth

Start here: find the failing layer

If wpctl status reports Could not connect to PipeWire, begin with the connection path. If it lists your speakers, begin with routing and mute. Reinstalling the sound server before making this distinction can turn a small routing problem into a package migration.

Open your desktop’s application menu and launch Terminal. Run a command as the user whose sound is broken, one command at a time. Do not copy a leading $ prompt. The examples here omit it. Never add sudo to wpctl or systemctl --user: root has a different session. A command that is not installed is a missing tool, not evidence that your sound card has disappeared.

How Linux audio actually reaches a speaker

A working card is only the beginning. The kernel driver exposes ALSA controls and playback/capture interfaces. An application needs a compatible interface, an available server, a selected route and a device configuration the hardware can use. A successful ALSA card listing proves registration at that layer; it does not prove the browser is sending a stream to that card.

PipeWire runs the multimedia graph. Applications can use its native API or compatibility libraries. PulseAudio-protocol clients normally reach pipewire-pulse on a PipeWire desktop. ALSA applications can reach PipeWire through the distribution’s ALSA plugin, while a client deliberately opening hw: accesses ALSA directly and may compete for the device. JACK applications can use PipeWire’s JACK implementation when the corresponding libraries are selected; a separately running JACK server is a different arrangement.

WirePlumber supplies policy: which devices to expose, profiles to activate, routes to restore and streams to link. It loads hardware monitors and controls graph objects. It is not a serial audio-processing stage between PipeWire and ALSA. Bluetooth takes the BlueZ/Bluetooth route instead of pretending to be a local ALSA card. See the PipeWire overview and WirePlumber components.

Read first, repair second

Use a quiet, known local audio file for playback comparisons. Confirm that the amplifier is on, the cable is in the intended socket and physical volume is low. A muted application and a sleeping digital receiver can produce the same silence for entirely different reasons. Write down what changed just before the problem: update, docking, a headset call, resume or switching monitors.

The following commands are observations. They do not apply a repair. Commands that open a client connection can trigger normal socket activation; “read-only” means they request no configuration change. The command reference includes permissions, expected evidence and limits. A reported state is a lead, not a verdict.

wpctl status

systemctl --user status pipewire.service pipewire.socket wireplumber.service pipewire-pulse.service --no-pager

journalctl --user -b -u pipewire.service -u wireplumber.service -u pipewire-pulse.service --no-pager -n 200

In the status listing, match names to the actual device and note the default marker. In the journal, read the first meaningful error at the failure time. A warning about an unused optional component is not equivalent to a failed audio graph. A nonzero exit from systemctl status is expected when a named unit is inactive or absent; read the displayed state.

“Could not connect”: server, socket or compatibility bridge?

The message establishes that this client did not connect to the selected PipeWire server. It does not identify why. A stopped server, wrong runtime directory, intentional remote override, missing package or different user can all lead here. WirePlumber can fail too, but a healthy PipeWire server can still accept a client while policy is missing. Keep these failures separate.

Inspect the service and socket. On a socket-activated installation an inactive service can be normal until a client connects. An active listening socket is evidence about activation, not evidence of a working speaker route. If a unit is masked, find out who masked it and why before undoing the policy. Do not enable standalone PulseAudio and its PipeWire replacement together as an experiment.

systemctl --user status pipewire.socket pipewire.service pipewire-pulse.socket --no-pager

pactl info

pactl info identifies the reachable PulseAudio-protocol server. A name containing “on PipeWire” identifies the compatibility server; a standalone PulseAudio system may have no reason to offer wpctl at all. If wpctl works but pactl cannot connect, inspect pipewire-pulse, its socket and any PULSE_SERVER override. Native and PulseAudio-protocol applications can fail differently.

systemctl --user start wireplumber.service

For “Device or resource busy”, identify the owner rather than killing every sound process. PipeWire holding a PCM is often normal. A second direct ALSA client or another server is a more specific lead. The shared ALSA ownership case contains the read-only owner check and its precautions.

The user session matters, especially with minimal desktops

Run the check inside the affected local desktop login. A root terminal, su, SSH login or container is not automatically the same audio environment. On a normal systemd/PAM login, the runtime directory belongs to the user and is commonly /run/user/<UID>. PipeWire uses runtime and remote environment variables to find the socket. The user manager and D-Bus session are related infrastructure, but an unavailable user bus is not the same error as a failed audio-device probe.

id -u

printenv XDG_RUNTIME_DIR PIPEWIRE_RUNTIME_DIR PIPEWIRE_REMOTE PULSE_SERVER

Do not “fix” this by inventing XDG_RUNTIME_DIR, changing ownership of another user’s runtime directory or hardcoding UID 1000. Compare a fresh terminal opened from the desktop first. If your own startup file exports a stale remote, save that exact file before removing that one override; restore it to roll back. For XMonad/dwm/startx setups, inspect the distribution’s supported login/session setup rather than copying another desktop’s environment blindly. X11 versus Wayland does not replace ALSA or PipeWire; session startup, permissions and portals can nevertheless differ. See pam_systemd.

PipeWire runs, but nothing useful is audible

Work from the graph toward the cable. Is the desired sink present? Is it default? Is the app playing into it? Is the sink muted? Does the selected card profile expose the required port? A monitor that was recently connected may become a playback target even when your speakers remain on the analog card.

wpctl get-volume @DEFAULT_AUDIO_SINK@

pactl list cards

A default applies to streams that use policy-selected destinations; existing streams can retain an application-specific target. Use your desktop sound controls or pavucontrol to move the actual playing stream. Record the old target before testing and restore it if the comparison fails. Likewise record the old card profile and port: profile switches can remove and recreate endpoints, interrupting playback and recording.

wpctl set-mute @DEFAULT_AUDIO_SINK@ 0

To choose a default from the command line, wpctl set-default ID takes a sink or source node ID from your current status, not a card ID. Write down the old default first; setting its current node ID restores the previous selection. For a physical mixer issue, use alsamixer, F6 to choose the card, F3 for playback and F4 for capture. Opening the mixer is not a reset; changing a switch is an action. Note original values and change only the relevant playback control.

WirePlumber 0.4 and 0.5: do not mix configuration formats

Check wireplumber --version before using a rule from a search result. WirePlumber 0.5 changed configuration to SPA-JSON and does not automatically migrate old Lua configuration. A copied full wireplumber.conf can also keep an old component layout alive after an upgrade. Upstream recommends fragments rather than maintaining a stale private copy of the vendor file.

On 0.5, user fragments normally live in ~/.config/wireplumber/wireplumber.conf.d/, or the equivalent under a customized XDG_CONFIG_HOME. On 0.4, legacy main.lua.d/bluetooth.lua.d instructions belong to a different format. Renaming a Lua file to .conf is not migration. Follow the upstream migration guide and fragment documentation.

systemctl --user restart wireplumber.service

Dummy Output and missing ALSA hardware

“Dummy Output” tells us there is no usable playback sink in that server context. Separate four observations: no ALSA card; a card without the needed PCM; a PCM without a PipeWire node; a node hidden by profile/route choices. Bluetooth is a separate hardware-monitor path and is not expected in aplay -l.

cat /proc/asound/cards

aplay -l

lspci -nnk

journalctl -k -b --no-pager -n 350

HD-Audio controllers and codecs are different pieces; the name snd_hda_intel does not mean “Intel hardware only”. A PCI device being listed does not prove a codec initialized. For SOF-based systems, a journal that names a missing firmware/topology file is useful evidence: match the exact filename and platform to your distribution’s firmware packages. Do not guess DSP driver switches, probe_mask or model= options from another laptop.

A kernel warning about switching to polling can be survivable; repeated probe failures and a missing card are a different situation. Compare with an already-installed previously working kernel if the loss followed an update. Keep the current and old boot options so that comparison is reversible. The kernel’s HD-Audio notes explain why hardware-specific quirks need evidence.

Microphones: source, capture path and app permission

Choose the physical source, not “Monitor of …”. Check a laptop privacy switch or headset mute before raising gain. Confirm the app selects that source; changing a system default does not necessarily replace a stored application selection. A moving desktop meter with no app meter suggests a different layer than a silent input everywhere.

arecord -l

wpctl get-volume @DEFAULT_AUDIO_SOURCE@

arecord -l enumerates capture hardware without recording. It does not prove the microphone receives a signal. For a deliberate recording test, use your desktop recorder with a clearly selected source, record only your own test speech, then delete the recording through your file manager when done. Review both system microphone access and the browser’s per-site permission. The ALSA recording guide documents capture switches and the limits of default-device tests.

Why a Bluetooth headset suddenly sounds like a telephone

Classic Bluetooth A2DP is normally the high-quality playback path. HSP/HFP provide bidirectional headset audio, with quality depending on codec and hardware support. Opening the headset microphone can therefore change playback quality. This is often a profile transition, not a broken sample rate or an underpowered CPU. A separate USB/analog microphone can let classic A2DP playback remain selected.

Watch the profile while the call app starts and stops capture. Close the microphone stream before comparing A2DP again. Record the previous app input and headset profile; restore them to undo the test. Do not disable every codec or globally force a profile before establishing the transition. LE Audio is a separate capability question: controller, headset, BlueZ, PipeWire and distribution configuration all matter.

For no connection at all, inspect the paired device in Bluetooth settings and verify it is not busy with another host. A BlueZ “Connected” state is not proof of a PipeWire sink. Bluetooth plugin packaging and active-session ownership are next checks. WirePlumber’s Bluetooth configuration describes seat monitoring; documented settings describe automatic profile switching. Do not disable seat monitoring merely to bypass the wrong login context.

One app, Steam, OBS, Discord or a browser is silent

If another app works on the same sink, keep that working baseline. Check the failing app’s mute, backend, output device and active stream. In OBS, a moving source meter does not prove that source is on the recording or streaming track you selected. In a browser, tab/site playback mute and microphone permission are separate. In Steam/Proton, establish whether the game creates a stream before changing global server settings or deleting prefixes.

pactl list sink-inputs

flatpak info --show-permissions APP_ID

For Flatpak, replace APP_ID with the installed ID. Its pulseaudio socket permission covers audio access even when the host server is PipeWire. A missing permission, an app override and a failing host compatibility server are different leads. Inspect first; use the app’s supported permission controls for a justified change and record the previous permission to restore it. Avoid blanket filesystem/device permissions. See the Flatpak permission reference.

Crackles, buffers and XRUNs: correlate before tuning

The graph processes audio in blocks. Quantum divided by sample rate gives the nominal block duration: 256 frames at 48 kHz is about 5.33 ms, not total microphone-to-speaker latency. Smaller blocks reduce one component of delay but leave less time to meet deadlines. Device buffers, converters, resampling, transport and the application add their own latency.

pw-top -b -n 5

In pw-top, observe QUANT/RATE, WAIT, BUSY and changes in ERR while the fault is audible. ERR includes XRUNs and other errors. A cumulative value from earlier playback does not prove the present crackle is a scheduling failure. Driver and follower nodes account for different timing; a driver can report a graph-wide miss caused elsewhere. Read the column definitions rather than treating a single large number as a diagnosis.

Compare the same local file at idle and under the workload that triggers the symptom. Then compare another output. USB resets call for transport/power/cable investigation, not a larger graph quantum. Bluetooth packet loss and clipping can sound like buffer trouble. If a professional app offers its own buffer setting, record it, change one step and compare; restore it if ineffective. Inspect realtime scheduling support and the distribution’s limits before changing priorities. Do not run the whole server as root.

pw-cli ls Node

pw-dump

My missing first two seconds: S/PDIF silence is not one problem

My old digital S/PDIF setup regularly swallowed roughly the first two seconds after a pause, seeking in a video or a short silent interval. Short notification sounds could disappear completely. That experience led me to write spdif-fix. I no longer use S/PDIF at this PC, but the distinction it taught me still matters: steady playback latency and a lost beginning after silence are different symptoms.

There are several possible transitions. An application can stop or disconnect its stream. Policy can suspend a node and close its ALSA device after idle. A digital receiver can lose its carrier/format synchronization or mute digital silence on its own. Keeping the server’s device open addresses one transition; it cannot promise that every external amplifier remains locked. These are hypotheses to compare, not a retrospective measurement of my receiver.

pactl list sinks short

Compare the exact sink during playback and after the interval. If it becomes SUSPENDED, a device-specific policy test is reasonable. If it remains active yet the receiver drops its signal indicator, investigate receiver behavior and the transport too. A running stream carrying zeros can still be treated as silence. Conversely a nonzero keepalive is not guaranteed inaudible and may change mixing, power use or passthrough behavior.

A narrowly scoped WirePlumber 0.5 example

First check wireplumber --version. This example uses the documented 0.5 configuration format. From wpctl status, choose your digital sink’s current ID, then inspect it to obtain the exact node.name. Replace the placeholder below with that value; do not use a wildcard matching all outputs. An ID is not a permanent name.

wpctl inspect ID

monitor.alsa.rules = [
  {
    matches = [
      { node.name = "REPLACE_WITH_EXACT_DIGITAL_SINK_NODE_NAME" }
    ]
    actions = {
      update-props = {
        session.suspend-timeout-seconds = 0
      }
    }
  }
]

Save it under ${XDG_CONFIG_HOME:-$HOME/.config}/wireplumber/wireplumber.conf.d/51-audio-rescue-spdif.conf. Restart only WirePlumber using the restart command above when no recording depends on it. Inspect its journal and the matched sink again, then repeat pause/seek tests with every other setting unchanged. Upstream documents that zero disables node suspend and leaves the ALSA device busy; it can increase power use and prevent another direct client from acquiring the device. See ALSA node rules.

How my S/PDIF fix helped me at the time

On my old S/PDIF setup, the sound card kept returning to power-saving mode even though I had already disabled it. After pausing or seeking, the beginning of the audio would regularly disappear. My S/PDIF fix helped me with exactly that problem: it played a continuous tone that I could not hear. This kept the sound card active instead of letting it return to power-saving mode. I used this workaround until I switched to an analog RCA connection.

The keepalive playback is provided by soundfixforautostart.sh, which starts a very low-level SoX tone. For my setup at the time, this was a practical solution to a particularly annoying everyday problem. I describe how I used it in more detail in the S/PDIF article.

HDMI and DisplayPort: a PCM is not a connected receiver

GPU audio can be registered even when the monitor, adapter or receiver exposes no usable audio capability. Check the actual display input, cable, receiver power and whether the screen has audio at all. Some adapters do not carry the desired format. ELD describes the connected receiver’s advertised audio capabilities; choose the file for the actual card and connector instead of assuming the first one.

cat /proc/asound/card0/eld#0.0

Read monitor_present, eld_valid, the monitor name and supported audio descriptors together. A valid record does not prove the correct profile or app route. If detection fails only after docking or sleep, compare ELD and the graph before and after reconnecting during a safe test; reconnecting interrupts display/audio. Restore the original connection and profile afterward. Avoid forcing a permanent profile to cover an unstable physical link.

USB DACs: transport, formats and clocks

lsusb

First ask whether USB enumerates the device, then whether ALSA registers its audio interfaces, then whether PipeWire exposes the expected nodes. Test a direct port and a known good cable before blaming the sound server. Keep the original connection documented so you can restore it; changing ports can change device identity or stored routes.

For an interface with rate/clock errors, the matching /proc/asound/cardN/streamM file lists supported formats. Replace both indices with your device’s values. Advertised rates do not establish external clock lock. Compare the application’s requested rate and channels with the correct playback/capture interface. A disconnect/reset in the kernel journal points to a different layer than growing graph deadline errors.

5.1 / 7.1, channel maps and encoded passthrough

Channel count, channel order and encoding are separate questions. Analog surround needs the right profile, jacks and cabling. HDMI multichannel PCM depends on receiver capability. Conventional S/PDIF generally carries stereo PCM or compatible compressed surround; selecting “7.1” cannot create the bandwidth for arbitrary multichannel PCM. A player’s passthrough setting also needs a codec the receiver can decode.

Compare stereo PCM first without a keepalive, then a known channel-identification sample at low volume on the intended profile. Record the original profile, player passthrough setting and any channel map before a targeted test; restore them afterward if it fails. Do not apply one forced audio.position map to every card. See the shared digital-profile case for IEC958 controls and its precautions.

After system suspend: compare before and after

A system sleep cycle is more than an idle playback node. USB can reconnect, GPU receiver information can change and a controller/firmware resume can fail. Capture a pre-sleep graph and compare device names, profiles and routes after resume. IDs may be reassigned. Read the kernel journal and the affected user journal around that event before restarting the service and erasing the most useful state.

If hardware disappears from ALSA, a routing tweak cannot restore its registration. If hardware remains but the app points at a retired endpoint, fix that route. If both remain, retain timestamps and the first error for a focused driver/server report. Compare a previously working installed kernel only when the evidence suggests a regression; keep a working boot option available.

Debian, Ubuntu, Fedora and Arch: package names are not interchangeable

Debian 13’s pipewire-audio metapackage includes the recommended desktop set, including WirePlumber, the PulseAudio bridge, ALSA integration and Bluetooth plugin. The installed package pipewire alone does not establish all those interfaces. Ubuntu releases can ship different WirePlumber branches: 24.04’s package family uses 0.4 libraries, while 26.10’s manifest lists a 0.5 daemon. Check the installed version, not the article date.

Fedora calls the PulseAudio replacement package pipewire-pulseaudio; do not assume Debian’s package name. Arch’s PipeWire reference describes separate compatibility packages and recommends a coherent system upgrade. Preview package transactions and removals before proceeding. This guide deliberately does not present one reinstall command as a universal repair. On a non-systemd installation, use its supported service manager; the graph and hardware distinctions still apply.

Questions that come up during diagnosis

Should I run wpctl with sudo?

No. Use the affected desktop account. A root process can have the wrong runtime and session, hiding the actual issue.

Does SUSPENDED mean my sound is broken?

No. It is often normal idle power management. Correlate the transition with your symptom and compare the exact device before testing a targeted rule.

Can I delete all audio configuration to start over?

Do not make that the first step. Read the journal, preserve the configuration and isolate one implicated fragment. A full reset destroys evidence and unrelated preferences.

Will changing the default fix every application?

Not necessarily. An existing stream or saved app setting can retain another target. Inspect the active stream too.

Does a higher buffer fix every crackle?

No. Deadline misses, clipping, transport loss and clock errors require different evidence. Compare counter changes during the audible fault.

What to keep when the result is still uncertain

Keep your distribution and installed PipeWire/WirePlumber versions, exact device model/USB or PCI identity, symptom trigger, first relevant error and one controlled before/after comparison. Keep raw logs local and redact usernames, paths, hostnames and device addresses before deliberately sharing selected lines. The assistant has no log-upload field and makes no repair decision for you.

All twelve existing Linux Fix Lab audio cases remain the shared source for their detailed diagnoses, precautions and rollback advice. The assistant adds navigation and new symptom distinctions around them; it embeds the current shared records at build time. Browse all audio cases, or use the Linux Hardware Explorer when device identification is the obstacle. For journal fundamentals, see journalctl troubleshooting.

Sources and verification

Documentation check: 27 October 2026. The upstream pages retrieved identify PipeWire documentation as 1.6.10 and WirePlumber documentation as 0.5.18; that is not a claim that every distribution ships those versions. Older installed manuals take precedence for option availability. The browser application is tested as software; a successful browser test is not an audio-hardware listening test.

1. PipeWire: server, runtime and clients
2. WirePlumber: wpctl
3. WirePlumber: components and profiles
4. WirePlumber: ALSA rules and node suspend
5. WirePlumber: migration 0.4 → 0.5
6. WirePlumber: configuration fragments
7. WirePlumber: Bluetooth monitor
8. WirePlumber: profile switching settings
9. PipeWire: pw-top column definitions
10. PipeWire: object / device properties
11. PipeWire: pw-cli
12. PipeWire: pw-dump
13. systemd: systemctl
14. systemd: login and runtime directories
15. Linux kernel: HD-Audio notes
16. ALSA: sound card testing
17. Flatpak: sandbox permissions
18. Ubuntu: pactl manual
19. Debian 13: pipewire-audio dependencies
20. Ubuntu 24.04: WirePlumber package family
21. Ubuntu 26.10: WirePlumber package
22. Fedora: pipewire-pulseaudio package
23. SPDIF-Fix: reviewed source