PulseAudio Restart Bug – Solved

I enjoy my Linux computers, and one reason is the fact that many technical issues can be resolved, without having to reboot endlessly. However, in my past usage, there has been an irritating exception to this pattern. It’s common under Linux, that we can simply restart the PulseAudio Server from the command-line, using one out of several methods, and that the subject should be done with. But alas, every time I have ever restarted PulseAudio in this way, or, if the server restarted on its own, afterwards, when looking up the Plasma 5 -generated status display (which is actually referred to as “Phonon”), I’d be missing a Devices List, like so:

Screenshot_20191026_152751

This type of display can be interpreted to mean several things, such as, that the PulseAudio server did restart, but that perhaps, it simply failed to connect to the inter-process, session-unique, message-bus. Therefore, in the past, whenever I had such a display, I eventually did what I thought I had to do, which was, to log out and back in again, or, to reboot. On my system, PulseAudio is configured such, that it runs as one user-name, and not as root.

In fact, a peculiar side effect of this bug was, that the list of available output devices was still being displayed, within ‘pavucontrol‘.

But this ordeal has now become even more inconvenient than it ever was because on the computer which I name ‘Phosphene’, the need may recur more frequently, ‘just to restart the PulseAudio server’.

However, I have finally found the true cause for this malfunction, which was, that when PulseAudio is restarted from within an existing session, it simply fails to load one module, which is also the module that it needs, in order to be able to list the available devices:

 


module-device-manager

 

In fact, there exists a script in ‘/usr/bin‘, that loads a series of X11-related modules.

Therefore, after a restart of this service, I can simply give the following command now:

 


/usr/bin/start-pulseaudio-x11

 

And Eureka! I can now obtain a list of available devices, without ever having to log out and back in, or, without ever having to reboot:

Screenshot_20191026_152853

In fact, I have created a shell-script, which I can click on as user, and which carries out this task, safely.


 

I’ve also discovered that the ‘ProjectM’ music visualization application still works, and detects the beat of the playing music as before. What this means is that theoretically, after ‘ProjectM’ was installed, instead of rebooting, I could have just restarted the PulseAudio server as described here, to get that working.


 

( Edited 2019/10/29, 23h35 … )

I know that there exists an unrelated problem, that just happens to give the same appearance within ‘Phonon’, but that cannot be resolved in this way…

( As of 2019/10/26 … )

I just wrote that the way my systems are configured, PulseAudio runs as user, and not as root. However nonsensical the situation may seem, it can sometimes happen that applications run as root, that have a full GUI, and that want to emit notification sounds. I can give settings telling these applications not to emit notifications, but some have been programmed to do so anyway.

What will happen in such a situation is, that the following directories end up belonging to user and group ‘root':

 


dirk@Phoenix:~$ su
Password:
root@Phoenix:/home/dirk# cd /run/user/1000
root@Phoenix:/run/user/1000# ls -l
total 0
drwx------ 2 dirk dirk 60 Oct 26 15:32 dconf
drwx------ 2 dirk dirk 40 Sep 30 17:45 gvfs
drwxr-xr-x 2 dirk dirk 40 Oct 25 12:42 KeePass
drwx------ 2 root root 80 Sep 30 17:43 pulse
drwxr-xr-x 2 dirk dirk 80 Sep 30 17:43 systemd
root@Phoenix:/run/user/1000#

 

If it should happen that the sub-directory ‘pulse’ ends up belonging to root, this will also give a corrupted display in ‘Phonon’, but then the solution is to give the command, as root:

 


root@Phoenix:/run/user/1000# chown -R dirk:dirk pulse

 

And the problem has gone away in the past (without requiring that PulseAudio even be restarted).


 

Now I suppose that one question which the reader may ask would be, ‘Why does Dirk suddenly feel that he will need to restart the PulseAudio server frequently, on the computer named Phosphene?’ And the answer will be, the realization that I’ll need to manipulate the TiMidiTy server after each reboot.

TiMidiTy is a server which acts as a MIDI player, that can be connected to via real-time MIDI controllers, and that plays them via SoundFonts and software. At least, that’s one of the ways in which it can be used. But because on my computers PulseAudio runs as user and requires authentication cookies from connecting clients, I already needed to modify the TiMidiTy service, to start as user. The way it gets packaged, it would start as root.

I’ve discovered that in addition, since an unknown point in time, the TiMidiTy server also needed to be started after PulseAudio, not before. (:1) To test this premise, I killed TiMidiTy and restarted it. However, the mere act of killing this process, if it started before PulseAudio, also crashes PulseAudio, after which PulseAudio restarts, but in the slightly corrupted state I wrote about. Thus, I’ll need to refresh the state of PulseAudio, and then restart TiMidiTy once, if I ever want to get real use out of TiMidiTy.


 

1:)

There’s a reason for which this doesn’t happen consistently on all my computers. It’s possible for PulseAudio to be configured, so that it doesn’t keep the sound devices active constantly. By default, PulseAudio will relinquish them if idle.

Meanwhile, if TiMidiTy is launched and PulseAudio not running, TiMidiTy will assume that it’s to connect to the output device using straight ALSA protocol. In that mode, TiMidiTy also doesn’t hog the device, but connects to it when the first MIDI sequences are input, and disconnects from it, as soon as the RT MIDI inputs are disconnected.

The problem starts when PulseAudio starts to keep the sound device connected constantly, even though PulseAudio started after TiMidiTy, which it does on the computer I name Phosphene. TiMidiTy hasn’t been notified that any change needs to take place, in how it would connect to the sound device. This means that as soon as a MIDI sequence is being received, TiMidiTy tries to grab the sound device as before, only to find that it can’t because something – i.e., PulseAudio – is keeping the sound device busy. So no notes are heard.

The real question, of why to kill TiMidiTy also crashes PulseAudio, remains unanswered to my mind. What I do know is that, if PulseAudio is running, when TiMidiTy is restarted, TiMidiTy plays nice with PulseAudio, as a client that this sound server can mix in to the combined output, so that TiMidiTy can share the default output devices with other PulseAudio clients. When started in that mode, killing TiMidiTy does not seem to crash PulseAudio.


 

(Update 2019/10/29, 23h35 : )

I think that I should add a note about the System Bell. What will happen with some Linux users is, that some of their software will generate ‘system beep’ sounds, that are meant to be played over a sound-generating device on the motherboard, and that are not even meant to be played through the sound card or sound chip. And, either because a certain motherboard does not recognize this little noise-making device, or because the user doesn’t like the sound of it, the user can override its use within the PulseAudio config, replacing it with a more pleasant sound-effect.

In order to find out, whether the kernel of your particular Linux system recognizes the little noise-maker, type in the following command as user:

 


lsmod | grep pcspkr

 

If this command returns a non-empty line, then the kernel has recognized the noise-maker. Yet, some users might want to override its use. The following article describes perfectly well how to do this:

https://unix.stackexchange.com/questions/407927/how-to-replace-system-beep-with-a-pleasant-sound-in-debian

But, with modern Linux versions, users may find it hard to test whether this works. And the reason would be as follows. Plasma 5 seems to avoid using the X11 messaging system for this beep, instead favouring that users set up sound-files to play, for any sort of event that Plasma 5 can recognize. Below is an example of what I mean:

Screenshot_20191029_231625

In order to test whether the PulseAudio module really works, it’s not just good enough to give the command:

 


echo -e "\a"

 

From within ‘Konsole’. What the user would need to do is to open an ‘xterm’ window from within Konsole, and then give the same command from within the ‘xterm’ window. The user will know whether the PulseAudio module works or not, because the same configured sound-effect will play with two distinct volume levels, depending on which application tries to play them.

 

Dirk

 

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.