How to Restart Sound Server In Fedora

Since I often work with different audio applications, DAWs more specifically like Ardour, LMMS, or Mixxx, the audio becomes disabled sometimes and I have a hard time restarting it. I don’t know how Linux audio works internally. I just know there is Alsa and Pulse and Jack. But, when the problem occurs, I don’t see any output. Gnome Desktop sound settings shows dummy output, nothing else. At this time, I cannot even play videos. They just don’t play, like the computer has been captured.
I saw some guides on running pulseaudio killall and pulseaudio -k, but none of them worked. It seems Ubuntu is more lenient in this, as major tutorials pertain to it.The last resort is to restart the computer at the moment.
So, is there a way to get out of this mess in an easier way each time it happens? Preferrably, a visual tool will be very good.
By the way, I read somewhere some time ago there is a new Audio protocol being developed for Linux that is supposed to solve such issues as well.

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:
    Untitled
    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.

3 Likes

Wow!

I should re-read your answer a couple of times, but thank you it was super-informative!

1 Like

I should’ve mentioned that JACK is one of the applications that (unavoidably) accesses the underlying hardware directly. So if jackd isn’t still running, but its previous use corrupted PulseAudio’s sound output, then you’d want to head down the path in choice 3.

The ALSA pulse: device, BTW, is provided by the alsa-plugins-pulseaudio package. I THINK that’s installed by default on Fedora systems these days (I certainly hope so!), but if not every single user should install it. And install the alsa-plugins-pulseaudio.i686 package as well, if you run any 32-bit audio applications. They will save you from countless headaches.