The audio dies after you wake the laptop
You close your laptop lid to grab coffee. You return, open the lid, and the screen wakes up. You click the volume icon. The slider moves. You play a video. Silence. You check the mute button. Nothing. The audio subsystem has gone dark after the suspend cycle. This is a common frustration on Fedora laptops, especially with modern hardware. The kernel dropped the audio device into a low-power state and failed to bring it back online cleanly.
Restart the service first. A reboot wastes time when a user-space restart takes seconds.
What is happening under the hood
When you suspend, the system tells the kernel to power down non-essential hardware. The audio driver saves the state of the codec and cuts power to the audio chip. On resume, the kernel should restore power and reload the driver state. Sometimes the hardware wakes up in a confused state. The codec reports it is ready, but the internal registers are scrambled. Or the user-space sound server loses its connection to the kernel driver and refuses to reconnect.
Fedora uses PipeWire by default on recent releases. PipeWire sits between applications and the kernel. It handles audio routing, device profiles, and sample rate conversion. If PipeWire crashes or hangs during the resume sequence, audio dies until you restart the service. The session manager, wireplumber, is responsible for detecting devices and applying profiles. If wireplumber fails to re-scan the hardware, the audio path remains broken even if PipeWire is running.
Older systems might still use PulseAudio. The symptom is the same. The fix depends on which sound server is active.
Check journalctl -xe if the restart does not help. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type journalctl -xeu pipewire muscle-memory style to isolate service logs.
Restart the sound server
The safest and fastest fix is to restart the user-space audio services. This forces a re-scan of the hardware and re-establishes the connection between applications and the kernel driver.
Here is how to check whether PipeWire is active on your system.
systemctl --user status pipewire
# WHY: Checks the state of the PipeWire service for your current user.
# Fedora 36 and newer ship PipeWire as the default audio server.
# If the output shows "active (running)", PipeWire is your sound server.
If PipeWire is active, restart the full audio stack. This includes the core daemon, the PulseAudio compatibility layer, and the session manager.
systemctl --user restart pipewire pipewire-pulse wireplumber
# WHY: Restarts the core audio daemon, the PulseAudio compatibility layer,
# and the session manager that configures audio devices.
# This forces a full re-scan of audio hardware and reloads device profiles.
# Using --user targets your session. Do not use sudo for user services.
If your system is running PulseAudio, the command differs. This happens on older Fedora releases or minimal installs where PipeWire was not selected.
pulseaudio -k && pulseaudio --start
# WHY: Kills the running PulseAudio daemon and immediately starts a fresh instance.
# This clears any hung state in the legacy sound server.
# The -k flag sends a termination signal. The && ensures the start
# command runs only if the kill succeeds.
Run the restart command. Audio should return within a second. If you hear a pop or a brief crackle, the hardware has re-initialized correctly.
Reload the kernel driver
Restarting the sound server fixes most cases. If the audio remains silent, the kernel driver itself may be stuck. The driver holds the low-level connection to the audio codec. If the driver fails to recover the hardware state, user-space services cannot recover either.
Here is how to force the kernel to re-initialize the audio hardware.
sudo rmmod snd_hda_intel && sudo modprobe snd_hda_intel
# WHY: Unloads and reloads the Intel HD Audio kernel module.
# This forces the kernel to re-initialize the hardware registers.
# Only use this if restarting PipeWire or PulseAudio does not work.
# This command drops all audio for a moment while the module reloads.
Some laptops use Sound Open Firmware or a different driver. If snd_hda_intel is not loaded, check which module is active.
lsmod | grep snd
# WHY: Lists all loaded sound kernel modules.
# Look for snd_hda_intel, snd_sof_intel_hda_common, or snd_soc_skl.
# Replace snd_hda_intel in the previous command with the correct module name.
Reload the kernel module only when necessary. Frequent module reloading can wear out hardware on some devices and causes audio dropouts during playback.
Prevent the issue permanently
If the audio fails after suspend every time, the hardware codec may not support the aggressive power-saving states enabled by default. You can disable power saving for the audio driver to keep the codec powered on during suspend. This prevents the hardware from entering a bad state.
Create a configuration file in /etc/modprobe.d/ to pass a parameter to the driver. Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
echo "options snd_hda_intel power_save=0" | sudo tee /etc/modprobe.d/audio-powersave.conf
# WHY: Writes a kernel module parameter to a persistent config file.
# The power_save=0 option disables aggressive power saving for the codec.
# This keeps the audio hardware active during suspend, preventing resume failures.
# This increases power consumption slightly on battery.
Apply the change by reloading the module or rebooting.
sudo rmmod snd_hda_intel && sudo modprobe snd_hda_intel
# WHY: Reloads the driver to pick up the new parameter from the config file.
# This avoids a full reboot to test the fix.
Test the fix by suspending and resuming the laptop. If the audio works reliably, the power-saving parameter resolved the hardware quirk.
Verify the fix
Visual indicators can be misleading. The volume slider may move even when the audio path is broken. Use a test command to confirm the audio path is functional from the kernel to the speaker.
Here is how to play a test tone to verify audio output.
speaker-test -c 2 -t wav
# WHY: Plays a test tone on the left and right channels.
# Confirms the audio path is functional from kernel to speaker.
# The -c 2 flag sets stereo output. The -t wav flag uses a WAV tone.
# Press Ctrl+C to stop the test.
If you hear the test tone, the audio subsystem is working. If you hear silence, check the output device selection in your desktop sound settings. PipeWire may have switched the default device to a dummy output or a disconnected Bluetooth headset.
Run the test tone. If you hear static, the audio is back. If not, check the next section.
Common pitfalls and error messages
If you run sudo systemctl restart pipewire, the command fails. PipeWire runs as a user service, not a system service. The sudo prefix targets the root user's instance, which does not exist. Use systemctl --user instead.
If the restart command returns Unit pipewire.service not found, your system might still be running PulseAudio. Check the active service with systemctl --user status pulseaudio.
If journalctl -xe shows snd_hda_intel: failed to load firmware, your kernel firmware package is out of date. Run sudo dnf upgrade --refresh to pull the latest linux-firmware package. The --refresh flag forces DNF to check for updated metadata, ensuring you get the newest packages. dnf upgrade --refresh is the normal weekly maintenance command.
If the audio comes back but sounds distorted or crackly, the sample rate might be mismatched. This often happens with Bluetooth headsets. Check the device properties in your desktop sound settings. PipeWire may have selected a profile with an unsupported sample rate.
SELinux denials can block audio access in rare cases, usually after custom configuration changes. SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. Disabling SELinux breaks security isolation and is rarely the correct fix for audio issues.
Trust the package manager. Manual file edits drift, snapshots stay. If you modified ALSA configs or PipeWire configs and audio broke, restore the defaults from the package.
Choose the right tool
Use systemctl --user restart pipewire pipewire-pulse wireplumber when audio is silent after suspend and you are on Fedora 36 or newer. Use pulseaudio -k && pulseaudio --start when you are on an older Fedora release or a custom minimal install that lacks PipeWire. Use sudo rmmod snd_hda_intel && sudo modprobe snd_hda_intel when restarting the sound server fails and the kernel driver appears stuck in a low-power state. Use options snd_hda_intel power_save=0 in a modprobe config when the audio fails after suspend on every cycle and you need a permanent hardware workaround. Stay on the default configuration when the audio works after a simple restart. Manual module blacklisting or custom ALSA configs introduce drift that breaks on kernel updates.