Dennis HilkLinux Fix LabDE

Audio, ALSA & PipeWire

Another process holds the ALSA device

Identify exclusive ALSA access that blocks PipeWire or a direct client, then release the verified owner or route the application through the sound server.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • PipeWire reports ALSA open failed: Device or resource busy.
  • Direct playback works only after another audio application closes.

Relevant environment

ALSA hardware PCMs used by PipeWire, jackd, PulseAudio or direct hw: clients; some devices allow only one opener.

Recognizable messages (synthetic examples)
pipewire[2140]: [alsa-pcm.c:1250 spa_alsa_open()] hw:0,0: playback open failed: Device or resource busy

Check the actual owner; hardware exclusivity differs from missing-card or mute problems.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • A direct ALSA application or second audio daemon can hold the same hardware PCM exclusively.
  • A PipeWire service holding its own expected hardware is normal; a direct-client busy error does not automatically mean PipeWire malfunction.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read processes using sound nodes. -v only reports owners; no kill option is included.

sudo fuser -v /dev/snd/*

Interpret the result: Identify the process, user and PCM device. PipeWire owning a playback PCM can be expected; a second direct owner or audio daemon deserves investigation.

Check 2

Read the affected user audio journal without restarting anything.

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

Interpret the result: An ALSA open busy report plus ownership evidence supports contention. A generic application busy message needs its backend and target verified first.

Evidence-guided next steps

Close the confirmed exclusive owner

If a known application unexpectedly owns the hardware, save its work and close it normally. If a second sound daemon is configured unintentionally, stop only that verified daemon using the distribution’s supported user-service workflow.

Precautions: Do not kill every /dev/snd user; that interrupts calls and recordings. Separate intended professional jackd sessions from accidental duplicate servers.

Recovery / rollback: Restart the closed application or restore the previous service choice if that owner was needed, keeping only one intended hardware owner.

Did this solution help you?

Share this solution#

Use a server-backed application output

If a direct hw: client conflicts with the desktop server, select its PipeWire or PulseAudio backend, or the distribution’s ALSA-to-PipeWire default where supported. Reserve direct hardware access for a deliberate exclusive session.

Precautions: Backend package names vary. Do not replace all ALSA device definitions or remove desktop audio packages solely because one direct client is busy.

Recovery / rollback: Restore the application’s recorded backend and device selection if compatibility regresses; close the desktop server deliberately before exclusive hardware use.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.