You upgraded to Fedora and the audio is gone
You upgraded from Fedora 39 to 40 and your desktop environment boots, but the sound icon shows a red cross. You plugged in a USB microphone and your recording software refuses to see it. You assume the hardware broke or the kernel dropped support for your sound card. It did not. The audio routing layer is likely asleep or fighting with a leftover PulseAudio configuration. Fedora switched to PipeWire as the default audio and video server years ago. Verifying that it is actually running takes three terminal commands and a clear understanding of how user sessions manage multimedia daemons.
What PipeWire actually does on your system
PipeWire replaces two older subsystems that used to fight for control of your sound hardware. It handles low-latency professional audio like JACK used to, and it handles desktop audio routing like PulseAudio used to. Think of it as a traffic controller for your sound cards, microphones, virtual streams, and screen capture pipelines. It runs inside your user session, not as a system-wide daemon. That means it starts when you log in and stops when you log out.
The architecture splits into three distinct units. The core pipewire daemon manages the actual audio and video graph. It allocates buffers, handles sample rate conversion, and routes streams between applications and hardware. The pipewire-pulse unit provides a compatibility layer. It speaks the PulseAudio protocol so legacy applications do not need recompilation. The wireplumber unit acts as the session manager. It reads configuration files, detects hardware changes, and tells PipeWire which profile to apply to each device. If wireplumber is missing, PipeWire has no map of your devices. If pipewire-pulse is down, applications that expect PulseAudio will fail silently. You need to check all three moving parts before assuming the hardware is broken.
Run systemctl status first. Read the actual error before guessing.
Check the services and session manager
Here is how to verify the core services are active and running under your user account.
systemctl --user status pipewire pipewire-pulse wireplumber
# --user targets the per-login session, not the system-wide daemon manager
# status shows the current state, recent log lines, and dependency tree
# pipewire handles the core audio/video routing graph
# pipewire-pulse provides the PulseAudio compatibility layer for older apps
# wireplumber acts as the session manager that configures device routing
Look for active (running) next to each unit. If you see inactive (dead) or failed, the service did not start during your login. Do not guess why it failed. The output contains the exact configuration error or missing dependency in the last five lines. If the services are down, start them manually and enable them for future logins.
systemctl --user start pipewire pipewire-pulse wireplumber
# start launches the units immediately in the current session
systemctl --user enable --now pipewire pipewire-pulse wireplumber
# enable creates the symlinks in ~/.config/systemd/user so they auto-start
# --now combines enable and start in a single transaction
Reboot before you debug. Half the time the symptom is gone after a clean login cycle.
Verify the audio server identity
Starting the services is not enough. You need to confirm your desktop is actually talking to PipeWire and not falling back to a legacy daemon. Applications query the audio server through the PULSE_SERVER environment variable or D-Bus. The pactl utility speaks the PulseAudio protocol, which PipeWire implements perfectly. Modern Fedora also ships wpctl, the native Wireplumber client, but pactl remains the standard for verifying the compatibility bridge.
pactl info | grep "Server Name"
# pactl queries the active audio server over the local socket
# grep filters the output to the single line that identifies the backend
A healthy Fedora system returns Server Name: PulseAudio (on PipeWire X.Y.Z). The version number after PipeWire changes with every release. If the output says Server Name: PulseAudio without the PipeWire suffix, you are running the standalone PulseAudio daemon. That happens when you manually installed pulseaudio alongside PipeWire, or when a third-party repository overwrote the default packages.
Run pactl info first. Read the actual server string before guessing.
Common pitfalls and error patterns
Several configuration patterns break PipeWire on Fedora. The most common is a leftover ~/.config/pulse/ directory from an older installation. PipeWire ignores it, but some desktop environments still read it and override the routing. Delete the directory and log out. The system will regenerate a clean configuration on the next login.
SELinux denials are rare but possible if you compiled PipeWire from source or moved configuration files outside the standard paths. Fedora ships PipeWire with correct SELinux contexts. If you see audio dropouts, check the audit log for access violations.
sudo ausearch -m avc -ts recent | grep pipewire
# ausearch queries the binary audit log for Access Vector Cache denials
# -m avc filters for security policy blocks
# -ts recent limits the search to the last few minutes
# grep isolates PipeWire-related blocks from other system denials
If the command returns lines starting with type=AVC, your custom configuration triggered a policy block. Restore the default contexts with sudo restorecon -Rv ~/.config/pipewire/. Never edit files in /usr/lib/pipewire/. Those files belong to the package manager. User modifications belong in /etc/pipewire/ or ~/.config/pipewire/. Manual file edits drift, snapshots stay.
Firewall rules do not block PipeWire. The daemon communicates over Unix domain sockets in your home directory, not over TCP or UDP. You do not need to run firewall-cmd for local audio routing. Focus on the session manager and the compatibility layer instead.
When a service fails to start, journalctl -xeu pipewire.service reads better than journalctl alone. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Use it to trace the exact line where the daemon aborted.
If you recently upgraded from Fedora 38 or older, the package manager might have left pulseaudio installed as a dependency for a legacy application. Remove it to prevent socket conflicts.
sudo dnf remove pulseaudio
# dnf removes the standalone daemon and its configuration files
# --setopt=clean_requirements_on_remove=True is default in modern Fedora
# removing pulseaudio forces all applications to use the PipeWire bridge
Trust the package manager. Manual file edits drift, snapshots stay.
When to use PipeWire versus alternatives
You need to choose the right audio stack for your workflow.
Use PipeWire when you want a unified audio and video server that handles desktop applications and professional recording tools without switching daemons. Use standalone PulseAudio when you are maintaining a legacy desktop environment that predates Fedora 34 and cannot be upgraded. Use JACK directly when you need hard real-time guarantees and are willing to compile kernel modules for low-latency scheduling. Stay on the default Fedora configuration if you only deviate from the defaults occasionally.