Microphone Not Working on Linux: How to Test & Fix It

On Linux, a microphone not working is far more often muted than broken. The ALSA capture channel ships disabled on many distributions, so the capsule works while the driver forwards nothing. A wrong default source, or an app confined to a sandbox, explains most of the remaining cases. The signal climbs a layered stack: the ALSA kernel driver, then PipeWire or PulseAudio, then the application itself. Any layer can drop it, and the result is always the same silence. The right fix depends entirely on which layer holds the block. This guide identifies that layer, then repairs it with both graphical and terminal steps. Start with a quick microphone test or the desktop input meter to confirm the hardware. Then find out whether your distribution runs PipeWire or PulseAudio, because the commands below branch on that answer.

Linux Microphone Not Working: Quick Fix Checklist

✓	Test with our microphone test or the desktop Sound input meter.
✓	Unmute the Capture channel in alsamixer and raise its level.
✓	Set the correct input in pavucontrol (or wpctl on PipeWire).
✓	Confirm your user is in the audio group.
✓	Restart audio: systemctl --user restart pipewire pipewire-pulse or pulseaudio -k.

Test your Linux microphone in under a minute

Confirm that the microphone captures sound before you change any setting. The fix for "no signal" differs completely from the fix for "signal, but nobody can hear me." A live input meter gives the fastest honest answer, because it reacts to your voice in real time. A record-then-play-back loop can hide device-selection mistakes, so start with a meter. Open our online microphone test and allow access when the browser asks. Now speak normally. If the level indicator moves as you talk, the microphone, the driver, and the sound server are all fine. The problem then sits higher up, in routing or in one specific app. If the meter stays flat, the signal is blocked or the wrong input is selected.

Test Your Microphone →

Your desktop also exposes the microphone natively. On GNOME, open Settings › Sound › Input and pick your device; the Input Level bar should move as you speak. On KDE Plasma, open System Settings › Audio and watch the meter beside the recording device. Suppose the bar moves here but an app still hears nothing. You have then proven the fault is app-specific rather than system-wide, so skip to the routing and permission sections below. The table maps the graphical places your desktop reveals the microphone, and what a reading in each one confirms.

Where to look	Path	What it confirms
GNOME input meter	Settings › Sound › Input	Whether the system receives a signal, and from which device
KDE audio panel	System Settings › Audio	The active recording device and its per-app routing
Volume Control	pavucontrol › Input Devices	Mute state, gain, and the selected hardware port
Recording tab	pavucontrol › Recording	Which app captures from which device, live

Know your sound server before you troubleshoot

Linux audio is layered, and the right fix depends on which layer is at fault. At the base sits ALSA, the kernel-level driver that talks to the sound card. Above it runs a sound server that mixes streams and routes them between apps. Two servers dominate. Modern distributions ship PipeWire. Fedora adopted it first, and Ubuntu has used it by default since version 22.10. PipeWire runs a compatibility layer called pipewire-pulse, so older tools still work unchanged. Older releases and some conservative setups still run PulseAudio. Both servers sit on top of ALSA, and a muted channel in ALSA will silence either one.

Identify your server before you spend time in the wrong tool. Run wpctl status in a terminal. A clean listing of sinks and sources means PipeWire is active. If the command is missing, you are most likely on PulseAudio; confirm with pactl info. This matters because the commands diverge. PipeWire is driven with wpctl, while PulseAudio uses pactl. The graphical tool pavucontrol works with both, because pipewire-pulse answers the same calls. The table below summarises the core tools and what each one does.

Tool	Type	What it does
pavucontrol	Graphical	Unmutes inputs, sets gain, picks the port, and shows per-app recording routes
alsamixer	Terminal (TUI)	Controls the raw ALSA card: capture mute, capture enable, and hardware gain
arecord / aplay	Terminal	Lists capture devices and records or plays a file straight through ALSA
wpctl	Terminal	Lists PipeWire devices, sets the default source, and mutes or unmutes it

Why a working microphone still goes silent on Linux

A muted ALSA capture channel is the number-one culprit

ALSA controls each capture channel independently, and one of them can be muted below everything else. When that happens, the desktop meter reads zero no matter how high you push the software volume. This single condition causes more "broken" Linux microphones than any hardware fault. The trap is that it is often invisible from the graphical mixer. The fix lives in alsamixer, a terminal mixer that exposes the raw card. Launch it, then press F6 to select your sound card. Press F4 to switch to the capture view. Highlight the Capture channel with the arrow keys. If it shows MM beneath the bar, it is muted; press M to unmute it. A capture channel must also be armed. Press Space on the selected item until it reads CAPTURE in red, then raise the level with the up arrow. Many laptops also expose an Internal Mic Boost control here, set to zero from the factory. Raising it revives a microphone that seemed dead.

The wrong default source and broken routing

The sound server chooses a default source, and it does not always choose the one you want. Plug in a USB headset, a webcam with a built-in microphone, or an HDMI capture device, and the server may promote it at once. Routing errors also hide inside individual apps. PipeWire and PulseAudio let each program record from a different device, set per stream. An app can therefore be pointed at a source that produces nothing while the system default works. The Recording tab in pavucontrol exposes this directly, listing every app currently capturing and the device it uses. Suspect routing first whenever the microphone works in one program but not another. Bluetooth headsets add a further wrinkle. A headset in the high-quality A2DP profile has no microphone at all. The system must switch it to the HSP/HFP profile before the boom mic appears, and audio quality drops when it does.

Permissions, groups, and sandboxed apps

Access control blocks the microphone in ways that leave no error message. Historically, a user had to belong to the audio group to reach the sound devices. Most modern desktops handle this through the session, but a minimal or server install may still require it. Sandboxing is the newer and larger problem. Applications packaged as Flatpak or Snap run inside a confinement layer that can deny microphone access even when the rest of the system works. The app then receives silence with no error. You inspect and grant these permissions with Flatseal, a graphical editor for Flatpak portals, or from the terminal with flatpak permissions. Browsers add their own separate layer on top. A site must be allowed inside the browser regardless of the system state. Our Firefox and Chrome guides cover that in-browser prompt in detail.

Fixing it, from the most common cause down

Work through these fixes in order. Do not jump to the dramatic ones. The sequence is deliberate. It resolves the most cases first, with the least disruption. Unmuting and routing together account for most Linux microphone failures. Only then does the sequence escalate to restarting the sound server. After each change, return to the microphone test or your desktop input meter. Re-check for a signal before moving on, so you always know which step made the difference.

Unmute and route with pavucontrol

Install and open pavucontrol first, because it fixes the most common failures graphically. Go to the Input Devices tab. Find your microphone, and confirm the mute button beside its level bar is not engaged. Raise the input volume if it sits low. Check the Port dropdown, since laptops often expose both an internal mic and a headset jack under one device. Now open the Recording tab while your app is live. Each listed app has a device selector on the right. Point the stubborn app explicitly at the correct microphone. This single reassignment resolves many "works everywhere but here" reports. Conferencing apps keep their own selector too, so also set the device inside them. Our guides for Zoom and Discord cover those panels step by step.

Enable capture in alsamixer, then test from the terminal

Drop to alsamixer when the graphical mixer shows a flat meter. Follow the unmute and capture-enable steps described above: F6 for the card, F4 for capture, then M and Space on the Capture channel. With the channel armed, verify the hardware path directly through ALSA. Run arecord -l to list every capture device the kernel sees. If your microphone is absent here, the fault is a driver or connection issue, not a settings one. If it appears, record a short clip and play it back with arecord -d 5 test.wav && aplay test.wav. Hearing your voice confirms the ALSA path works, which narrows the fault to the server or the app. On PipeWire, do the same job with wpctl status to read the source ID, then wpctl set-default <id> and wpctl set-mute <id> 0.

Restart the sound server when the meter stays frozen

Suppose the channel is unmuted, the correct source is selected, and the meter still will not budge. The sound server has probably wedged. This is a known state after suspend, after hot-swapping a USB interface, or after a driver update. Restarting the server forces the whole audio graph to rebuild without a reboot. On PipeWire, run systemctl --user restart pipewire pipewire-pulse wireplumber. On PulseAudio, run pulseaudio -k, and the daemon relaunches automatically. Audio cuts briefly as it does. Treat this as the reset button for a frozen stack, not a routine step. The matrix below maps common symptoms to their usual cause and the fastest fix.

Symptom	Likely cause	Fix
Desktop meter flat, all devices	Capture channel muted in ALSA	Unmute and arm Capture in alsamixer (M, then Space)
Works in one app, not another	Per-app routing to the wrong source	Reassign the device in pavucontrol › Recording
Mic gone after plugging a headset	Default source moved to a new device	Set the source with wpctl set-default or pavucontrol
Bluetooth headset mic missing	Device is in the A2DP profile	Switch it to HSP/HFP in the pavucontrol profile list
Only one app hears silence	Flatpak or Snap sandbox blocks the mic	Grant access in Flatseal or via flatpak permissions
Signal returns after every reboot only	Sound server wedged after suspend	Restart pipewire and wireplumber, or run pulseaudio -k

Keeping your Linux microphone reliable

A few habits keep the microphone working once it is back. Keep the system updated, since PipeWire and WirePlumber ship frequent routing and Bluetooth fixes. Pin the microphone you want as the default source, so a newly connected headset cannot silently steal the slot. Review your Flatpak permissions from time to time, and grant microphone access only to apps that need it. When the microphone must work across a browser, a desktop app, and the terminal, test it in each place. One that records perfectly with arecord can still be blocked one layer up, inside a sandbox or a browser tab. Behaviour also varies by distribution and desktop, so a Fedora fix may sit under another menu on Ubuntu. If you switch between machines, our Chromebook guide covers the same checks on ChromeOS.

Frequently Asked Questions

How do I know whether my system uses PipeWire or PulseAudio?

Run wpctl status in a terminal. A listing of sinks and sources means PipeWire is running. If the command is missing, run pactl info and read the Server Name line. Fedora and Ubuntu 22.10 or newer default to PipeWire; older releases use PulseAudio.

My microphone works with arecord but not in my apps. Why?

A working arecord capture proves the ALSA hardware path is fine. The fault sits in the sound server or the app. Open the Recording tab in pavucontrol and point the app at the correct source. If the app is a Flatpak, check its microphone permission in Flatseal.

Why does my Bluetooth headset microphone not appear?

High-quality A2DP mode carries no microphone. The headset must switch to the HSP or HFP profile before its boom mic is available. Open pavucontrol, find the device under the Configuration or profile list, and select the headset profile. Expect the audio quality to drop when you do.

How do I unmute the microphone from the terminal?

On ALSA, open alsamixer, press F4 for the capture view, select Capture, and press M to unmute. On PipeWire, find the source ID with wpctl status, then run wpctl set-mute <id> 0. A muted ALSA capture channel is the most common cause of a silent input.

How do I restart Linux audio without rebooting?

On PipeWire, run systemctl --user restart pipewire pipewire-pulse wireplumber. On PulseAudio, run pulseaudio -k and the daemon restarts itself. Audio cuts for a second while the server rebuilds its graph. Use this only after unmuting and routing checks have failed.