You plugged in the headset and the meter stays flat
You join a video call. You open your recording application. The level meter refuses to move. You check the physical connection. You toggle the hardware mute switch. The microphone is silent. This happens after a dnf upgrade, after the system wakes from sleep, or sometimes for no apparent reason. Fedora uses PipeWire for audio management, which is robust, but the user session services can drift out of sync with the kernel drivers. The fix is usually a service restart, not a configuration rewrite.
The audio stack and why it drifts
Fedora replaced PulseAudio with PipeWire. PipeWire handles low-level audio streaming and device management. WirePlumber manages the session, routes streams to ports, and applies policies. Applications talk to PipeWire through a PulseAudio compatibility layer.
PipeWire builds a graph of nodes. Sources, sinks, filters, and streams connect in this graph. WirePlumber watches udev events and updates the graph when hardware changes. When a device disconnects and reconnects, or when a kernel module reloads, udev fires events. WirePlumber catches these and modifies the graph.
Sometimes the event stream gets out of order. WirePlumber might hold a stale reference to a device node that no longer exists. The graph becomes inconsistent. The microphone node exists, but the routing path is broken. Restarting the user services drops the graph and forces a full rebuild from scratch. This clears stale state without rebooting the machine.
Configuration files for PipeWire live in ~/.config/pipewire/ for user overrides. The system defaults ship in /usr/lib/pipewire/. Never edit files in /usr/lib/. Package updates will overwrite them. Copy the file to ~/.config/ and modify the copy.
Restart the session services
Restart the audio stack services to force a hardware re-scan and clear stale session state.
systemctl --user restart pipewire pipewire-pulse wireplumber
# --user targets the session services, not the system-wide daemons
# pipewire handles the low-level audio graph and device management
# pipewire-pulse provides the compatibility layer for older apps
# wireplumber manages session policies and routes streams to ports
# Restarting all three ensures the routing graph rebuilds cleanly
Audio services run in the user namespace. You do not need sudo to restart them. Using sudo here targets the wrong instance and will fail or have no effect. The --user flag is the standard pattern for desktop services.
Restart the services before you reboot. A full reboot wastes time when the session state is the only problem.
Verify the source is active
Check the source list to confirm the microphone appears and is not muted by the system.
pactl list sources short
# pactl queries the PulseAudio compatibility layer
# This lists all detected audio sources with their index and name
# Look for your microphone device in the output
# The last column shows the mute state as [no] or [yes]
If the device shows [yes] in the mute column, the system has muted it. Unmute it with pactl set-source-mute <index> 0. The index is the first number in the line.
If pactl returns Connection refused, the pipewire-pulse service is not running. Check the service status with systemctl --user status pipewire-pulse. If the service is dead, inspect the logs with journalctl --user -u pipewire-pulse -xe. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style.
Run pactl first. If the source is missing, the issue is lower than the session manager.
Common failure modes
The microphone can fail for reasons other than a stale graph. Check these patterns before digging into kernel logs.
Profile mismatch. Many headsets expose multiple profiles. A headset might offer "Headphones" for output only, or "Headset Head Unit" for input and output. If the profile is set to output-only, the microphone will not appear as a source.
Application mute. The system graph can be correct while the application mutes the stream. Desktop environments often show a global mute toggle. Applications like Zoom, OBS, or Firefox have their own mute buttons. The global mute does not always override the app setting.
Bluetooth codec negotiation. Bluetooth microphones often default to a low-quality codec or fail to negotiate the input stream. PipeWire supports high-quality codecs like LDAC or aptX, but the configuration requires specific modules. If your Bluetooth mic works for music but not voice, the profile negotiation might be stuck.
Use wpctl to inspect the device profile and volume levels directly in the terminal.
wpctl status
# wpctl is the native client for PipeWire
# This shows the current audio graph and active streams
# Check the "Sources" section for your microphone
# Ensure the volume is not zero and the profile is correct
For Bluetooth devices, verify the profile supports input.
wpctl status | grep -A 5 "Bluetooth"
# grep filters the status output for Bluetooth devices
# -A 5 shows the device and the next five lines of context
# Check the profile line for "Headset Head Unit" or "A2DP Sink"
# A2DP Sink supports high-quality playback but often lacks input
# Headset Head Unit supports both input and output at lower quality
If the profile is wrong, switch it with wpctl set-profile <device_id> <profile_name>. Get the device ID from wpctl status.
Check the profile. A headset set to "Headphones" will never capture audio.
Debugging the kernel layer
If the service restart and profile checks fail, the issue might be in the kernel driver. The driver could have failed to probe the hardware, or the firmware might be missing.
Inspect the kernel logs to determine if the hardware is detected at the driver level.
journalctl -k --grep="snd|audio|mic" --no-pager | tail -20
# -k filters for kernel messages only
# --grep searches for audio-related subsystem tags
# --no-pager dumps output to stdout for scripting
# tail limits the output to the most recent entries
# Look for errors like "probe failed" or "firmware missing"
If you see probe failed, the driver loaded but could not initialize the device. This often points to a hardware fault or a BIOS setting. If you see firmware missing, install the firmware package. Fedora splits firmware into separate packages for licensing reasons.
dnf install linux-firmware
# linux-firmware contains non-free firmware blobs
# Many audio codecs require these blobs to function
# dnf will only download the missing files if needed
Read the kernel log. If the driver fails to probe, no amount of service restarting will help.
When to use this vs alternatives
Use systemctl --user restart when the device was working and suddenly stopped after an update or sleep cycle.
Use a full reboot when the kernel module fails to load or the device does not appear in lsusb or dmesg.
Use pavucontrol when you need to change the input device or adjust per-application volume levels.
Use wpctl set-profile when the device is detected but the profile restricts input or output.
Use dnf install linux-firmware when the kernel logs show missing firmware blobs for your audio codec.
Use rfkill unblock all when the hardware switch is engaged or the radio is soft-blocked.
Trust the package manager. Manual file edits drift, snapshots stay.