How to Restart Sound Server In Fedora

Ask Fedora
, ,
2

Well, last things first. Yes, there’s talk of PipeWire being a potential successor to PulseAudio and JACK as the default sound server for desktop systems, since (like PulseAudio) it can operate over a network and interface with a heterogeneous collection of remote and local audio sinks/sources, and (like JACK) it has a focus on low-latency performance suitable for realtime audio processing. Plus, it handles video as well as audio, which is an advantage for streaming or remote multimedia applications.

However, PipeWire would still be a layer on top of the system hardware device backends like ALSA, OSS, BlueZ (for Bluetooth audio hardware), etc. So, while it has the potential to modernize some aspects of the high-level “sound server” layer, it will not be a panacea for all form of audio woes, especially those related to hardware device interfacing. IOW, PipeWire is no guarantee that the sort of issues you’re seeing will be completely eliminated.

Now, on to the issues you’re seeing.

PulseAudio is indeed the default/system sound service when running in a standard GNOME Shell session, and while opinions vary, in my experience it’s fairly well-behaved for typical enduser use cases when left to its own devices. (No pun intended, I swear.)

If you’re having issues with garbled sound or hanging connections, most likely one or more of the applications you’re using is either (a) activating JACK, or (b) going “behind PulseAudio’s back” and interfacing directly with the ALSA sound hardware devices. There are valid reasons for doing both. (As I said, JACK is a more performance-focused sound system than PulseAudio, so it’s preferred by some production/high-end audio applications. Whereas not every application has been enhanced with support for PulseAudio, and ones that aren’t have no choice but to rely on their existing ALSA compatibility.)

Regardless, when you get into these situations, the solution largely depends on the nature of the problem (as there are several possibilities).

  1. jackd was launched, and is still running
    Solution: Kill it. (killall jackd). See if you can reconfigure whatever’s starting it to add the -T (temporary) flag to its command line, which will tell it to auto-terminate when its clients have exited.

  2. Some application accessed the sound hardware directly using ALSA, breaking/corrupting PulseAudio’s connection to that device.
    So.lution: First, if at all possible try not to access your primary audio output device directly using ALSA. (If it’s a secondary device that PulseAudio can just ignore, that’s different. But if that were the case, we wouldn’t be having this conversation.)

    When PulseAudio is active on the system, a virtual ALSA device pulse: is created that represents an emulated ALSA interface to PulseAudio, usable by software with no direct PulseAudio support. Using that device, rather than a direct hardware interface like hw:0,0 — even/especially if it’s ultimately the same hardware device — will be much less disruptive to the rest of the system.

    For example, here’s the list of sound device selections I get from Audacity (which doesn’t support PulseAudio directly) when I have its ALSA backend selected:
    133b19496ea38f344eb3a21757e41cc044524935.png
    If I use either pulse or default (which is pulse), to send audio to my USB audio interface (the primary sound output for my system), I will have far fewer problems than if I select the “USB Audio Device: #1 (hw:2,1)” direct hardware interface to that device. If I connect Audacity directly to the hardware, the rest of the system typically can’t use it, so my overall system sound ends up broken in small or big ways.

  3. You needed to directly interface some software with an ALSA hardware device, for performance / fidelity / exclusivity reasons, and now you want to fix PulseAudio’s access to it.
    Solution: Assuming you’ve already terminated the application with the direct hardware connection, depends on the nature of the “damage”.

    • pulseaudio -k is indeed the way to restart the sound server. However, corruption issues are rarely caused by the server itself, and it restarts with all of the same device parameters it previously had, so there’s every chance a restarted server will have the same issues.

    • If the issue is in how PulseAudio is accessing the device, you can often clear up garbled audio and similar quality issues by resetting the sink for that hardware. And, bonus, the process is indeed graphical.

      If you install the paman package using dnf, you’ll have a “PulseAudio Manager” utility you can run to manage all of PulseAudio’s modules, devices, and clients. The “Devices” tab shows each Sink and Source (playback and recording interfaces), along with the clients connected to each of them. I find that a lot of audio corruption issues can be fixed by double-clicking the problem sink (the one for the hardware device with garbled output), then hitting “Reset” next to its Volume slider. (Which will set the volume to 100%, so — careful! Best not to have anything playing at that time.)

    • If resetting things in PulseAudio doesn’t work, the issue may be with the underlying ALSA driver. aplay -l (that’s a letter ell, not a number one — this monospace font sucks) will show you a “List of PLAYBACK Hardware Devices” (says so right at the top!), but the important parameter is the card number for each device. Check which card# is the device that’s causing problems, and try a sudo alsactl init # to reinitialize the hardware driver for that card. And then maybe do a pulseaudio -k for good measure, too.

I’m sure there are still more pathologies I haven’t even covered here (heck, I didn’t even touch on Bluetooth audio, a favorite for corruption and all manner of performance issues), but hopefully this is at least some help in mapping out the different parts of the insane mess that is Linux sound support.

12 Likes