You want PulseAudio back. Fedora 42 says no.
You upgraded to Fedora 42 and your audio started glitching. Or maybe a specific application refuses to play sound, or the volume slider behaves strangely. You remember a time when pulseaudio was the standard and you had a script to fix volume levels or a workaround for a Bluetooth headset. You want to revert to PulseAudio.
The short answer is you cannot revert. Fedora 42 removed the pulseaudio package from the repositories. The system is built around PipeWire. Attempting to force PulseAudio back requires removing core dependencies, patching broken links, and fighting the package manager. The result is a system that fails to update, crashes on boot, or leaves you with silent speakers. Fix the audio issue instead of changing the architecture.
What PipeWire actually does
PipeWire replaces PulseAudio, JACK, and ALSA plugins in a single daemon. It uses a graph-based topology. Each audio stream is a node. Connections are edges. This allows dynamic routing between applications, hardware, and virtual devices. PulseAudio was a flat mixer. PipeWire is a network.
Fedora adopted PipeWire to handle the complexity of modern audio. Bluetooth LE Audio, spatial audio, screen recording with audio, and low-latency pro audio all require features that PulseAudio could not provide. The architecture shift is fundamental. PipeWire sits closer to the kernel and manages resources more efficiently. It handles codec switching on the fly and supports multiple profiles per device without restarting the daemon.
Reverting to PulseAudio means removing the foundation. The pulseaudio package no longer exists in Fedora 42. Even if you could install an old RPM, the dependencies are gone. Libraries have been replaced. The kernel interfaces have evolved. You would be patching a hole in the floor by removing the floor. The system expects PipeWire. Applications expect PipeWire. The configuration files expect PipeWire.
The compatibility layer saves your apps
You might think reverting is necessary because your apps use PulseAudio. They do not need PulseAudio. They need the PulseAudio protocol. PipeWire provides this through a compatibility layer called pipewire-pulse.
This library speaks the PulseAudio protocol. Applications that ask for PulseAudio get routed to PipeWire transparently. Commands like pactl and pacmd still work because they talk to pipewire-pulse, which translates the requests to PipeWire. You are not running PulseAudio. You are running PipeWire pretending to be PulseAudio. This layer is the bridge. Breaking the bridge breaks the apps.
The compatibility layer is installed by default. It is enabled in the PipeWire configuration. If your apps are failing, the issue is not the absence of PulseAudio. The issue is a misconfiguration in PipeWire or WirePlumber, a driver problem, or a hardware fault. Debug the current stack. Do not chase a ghost.
Troubleshoot the audio stack
Most audio issues stem from configuration drift or a hung session manager. The audio stack is user-space. System-level commands often miss the problem. Always check the user service. PipeWire and WirePlumber run per-user. The system-wide service manager does not control them.
Check the status of the user services. Both must be active. PipeWire handles the audio processing. WirePlumber loads the configuration and manages the graph. If WirePlumber crashes, PipeWire runs without a brain. Audio streams won't connect.
systemctl --user status pipewire wireplumber
# WHY: PipeWire and WirePlumber run as user services. System-level status checks show nothing.
# The --user flag queries the user session manager. Both services must be active.
# Look for "active (running)" in the output. If either is failed, note the error line.
If a service is failed, restart it. Restarting WirePlumber is usually the first step. WirePlumber reloads the configuration and rebuilds the graph. This fixes issues caused by config syntax errors or stale state.
systemctl --user restart wireplumber pipewire
# WHY: Restarting WirePlumber forces a reload of the configuration files.
# Restarting PipeWire ensures the daemon picks up the new graph.
# Order matters: WirePlumber should start before PipeWire connects streams.
Check the journal for errors. The journal shows why a service failed or why audio is silent. Look for Failed to load module, Connection refused, or Permission denied. These point to specific problems.
journalctl --user -xeu wireplumber
# WHY: The -x flag adds explanatory text for common errors.
# The -e flag jumps to the end of the journal.
# The -u flag filters for the wireplumber unit.
# Read the last 20 lines. Errors usually appear right before a restart or crash.
If the journal shows no errors but audio is silent, check the default sink. WirePlumber might have set the wrong output device. List the available sinks and set the correct one.
wpctl status
# WHY: wpctl is the PipeWire control tool. It shows the current graph state.
# Look for the "Audio/Video" section. Identify the sink you want to use.
# Note the name in brackets, e.g., [alsa_output.pci-0000_00_1f.3.analog-stereo].
Set the default sink using the name you found. This tells WirePlumber to route new streams to that device.
wpctl set-default alsa_output.pci-0000_00_1f.3.analog-stereo
# WHY: This command updates the default sink in WirePlumber.
# New applications will use this output automatically.
# Existing applications may need to be restarted to switch.
Check the user services. A reboot is the nuclear option. Service restarts are surgical.
Verify the fix
Play a test sound to confirm the audio path is working. Use a tool that bypasses application-specific audio handling. This isolates the problem to the system stack.
pw-play /usr/share/sounds/freedesktop/stereo/complete.oga
# WHY: pw-play is part of the PipeWire tools. It sends audio directly to PipeWire.
# If this plays, the stack is working. The issue is in your application.
# If this fails, the stack is broken. Continue debugging the system.
If the test sound plays, your audio is fixed. The issue was likely a hung service or wrong default sink. If the test sound fails, check the hardware. Ensure the device is not muted in wpctl status. Check the kernel logs for driver errors.
Hear the beep? The path is clear. If not, the hardware or driver is the blocker, not the server.
Common errors and recovery
Audio errors on Fedora usually fall into three categories. WirePlumber fails to load a module. PipeWire cannot connect to the hardware. Bluetooth codec negotiation fails.
If you see Failed to connect to server: Connection refused, PipeWire is not running. Start the user service. This error often appears after a long sleep or a resume from hibernation. The user session manager might have dropped the service.
systemctl --user start pipewire wireplumber
# WHY: Manual start recovers the services after a session drop.
# This is safer than rebooting. The services will auto-start on login.
# If this fails, check the journal for the root cause.
If you see Module load failed: libpipewire-module-protocol-pulse.so, the compatibility layer is missing or broken. This is rare on default Fedora. It happens if you manually edited configuration files or installed a third-party repo. Restore the default configuration.
dnf reinstall pipewire-pulse wireplumber
# WHY: Reinstalling replaces modified configuration files with package defaults.
# This fixes syntax errors or missing modules caused by manual edits.
# Always edit /etc/pipewire/ or ~/.config/pipewire/. Never edit /usr/lib/pipewire/.
If Bluetooth audio is choppy or disconnects, check the codec. PipeWire supports multiple codecs. The default might not match your headset. Check the active profile.
wpctl status | grep -A 5 "Bluetooth"
# WHY: This shows the Bluetooth device and its current profile.
# Look for "A2DP" or "HSP/HFP". A2DP is high quality but one-way.
# HSP/HFP is lower quality but supports the microphone.
# Switch profiles if the wrong one is active.
WirePlumber manages the graph. If WirePlumber is dead, PipeWire has no brain. Restart the manager, not the daemon.
Choose the right audio stack
Fedora provides a single default stack for a reason. The stack is tested, maintained, and integrated. Deviating from the default introduces risk. Choose your approach based on your needs.
Use PipeWire when you need Bluetooth audio, screen recording, and low-latency playback without manual routing.
Use ALSA when you are debugging kernel drivers or running a headless system with no mixer requirements.
Use JACK when you require professional audio workflows with sample-accurate sync and you accept the complexity of manual port connections.
Stay on the default stack when you want updates to succeed without dependency conflicts.