Dennis HilkLinux Fix LabDE

Audio, ALSA & PipeWire

The microphone is visible but records silence

Trace microphone silence across PipeWire source selection, capture switches and application permissions, without mistaking a monitor source for a real mic.

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 input exists but its level meter stays at zero.
  • An application captures speaker output or the wrong microphone.

Relevant environment

PipeWire/WirePlumber desktops with analog, USB or built-in microphones; sandboxed applications can add their own permission layer.

Possible causes

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

  • A muted source, wrong default or retained application target can route the wrong input.
  • Hardware privacy switches, ALSA capture switches, the selected input port or app permissions can block capture independently.

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 sources, default marker and running recording streams as the affected desktop user.

wpctl status

Interpret the result: A source with monitor semantics captures output rather than the physical microphone. A visible real source without a stream may indicate application selection or permission issues.

Check 2

Read the default input’s current volume and mute state; no recording is created.

wpctl get-volume @DEFAULT_AUDIO_SOURCE@

Interpret the result: [MUTED] explains source silence, but an unmuted value does not verify the hardware capture switch, input port or app permission.

Evidence-guided next steps

Select and unmute the physical microphone

If the wrong source or mute state is confirmed, select the actual microphone in the desktop audio input panel and the application, then unmute only that input. Check the physical privacy switch and the appropriate ALSA capture control if the meter remains silent.

Precautions: Avoid excessive boost, which can introduce noise or feedback. Explain that restoring capture also restores microphone access to authorized applications.

Recovery / rollback: Restore previous input, gain, mute and privacy-switch settings after the comparison or when capture is no longer wanted.

Did this solution help you?

Share this solution#

Review the affected application’s capture access

If the desktop meter responds but only one application records silence, review its selected microphone, per-app recording mute and its browser or sandbox microphone permission. Grant access only to the intended application and retest its capture stream.

Precautions: Do not globally relax sandbox permissions or device-node access because one app cannot record. Save calls or recordings before restarting an app.

Recovery / rollback: Revoke the temporary microphone permission and restore the prior app input if it was unnecessary or did not solve the issue.

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.