Dennis HilkLinux Fix LabDE

Audio, ALSA & PipeWire

ALSA cannot see the expected sound card

Locate a missing sound card below PipeWire by checking ALSA enumeration and kernel probing, before changing desktop routes or user audio settings.

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

  • The expected hardware is absent from /proc/asound/cards.
  • The desktop offers only a dummy output or unrelated HDMI card.

Relevant environment

PCI HD-Audio, USB audio or firmware-driven sound hardware using ALSA kernel drivers.

Recognizable messages (synthetic examples)
snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to polling mode: last cmd=0x001f0000

This can be relatively harmless; confirm missing cards or actual playback failure before applying a quirk.

snd_hda_intel 0000:00:1f.3: azx_get_response timeout, switching to single_cmd mode: last cmd=0x001f0000

Review codec-probing evidence and exact controller identity; do not assign this to PipeWire mute settings.

Possible causes

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

  • Missing driver binding, failed codec probing or required firmware can prevent ALSA card registration.
  • Firmware setup can disable onboard audio, and a disconnected USB device is a separate enumeration failure.

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 registered ALSA cards as your normal user; this does not initialize a playback stream.

cat /proc/asound/cards

Interpret the result: No expected card places the issue below PipeWire routing. A present card without playback PCMs still needs codec and profile checks.

Check 2

Read kernel probe messages with journal access if necessary. Compare snd_hda, SOF and USB events with the expected device.

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

Interpret the result: Missing firmware or codec probe errors justify driver-layer work. A polling fallback warning alone may be harmless if the card and playback work.

Evidence-guided next steps

Restore device detection and required firmware

If the device is disabled or absent from the bus, check firmware audio settings and the physical USB connection first. If the kernel names a missing sound firmware file, install the distribution’s matching firmware package and rebuild its boot image only if that platform requires it.

Precautions: Use the hardware model and exact filename; avoid switching Intel DSP drivers or copying arbitrary firmware as a blanket fix.

Recovery / rollback: Restore recorded firmware settings or boot the previous kernel/image if detection worsens. Keep the package change limited to the required firmware.

Did this solution help you?

Share this solution#

Compare a kernel probe regression

If the card disappeared after a kernel update, boot a previously working installed kernel and compare ALSA registration. For confirmed HDA codec-probing errors, collect codec and PCI IDs before considering a documented device-specific quirk.

Precautions: Do not guess probe_mask or model settings across multiple sound controllers; they can hide working codecs.

Recovery / rollback: Boot the original entry and remove only the experimental sound-driver option if the comparison is unsuccessful.

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.