I happen to have an older laptop, which I name ‘Klystron’, that is running Debian 8 / Jessie, with KDE 4 as its desktop manager. Don’t ask me why, but I tend to leave older builds of Linux running on some of my computers, just because they seem to be running without any deficiencies.
That laptop has lousy speakers. I decided a few days ago, that it would benefit, if I could get the 14-band graphical equalizer to work, that is generally available on Linux computers which, like that laptop, use the ‘PulseAudio’ sound server. However, on this old version of Linux, achieving that was a bit harder than it’s supposed to be. Yet, because I succeeded, I felt that I should share with the community, what the steps were, needed to succeed.
First of all, this is what the equalizer looks like, which I can now open on that laptop:
And it works!
In order to get this sort of equalizer working with PulseAudio, eventually, the following two modules need to be loaded:
And, if I gave the command ‘load-module…’ naively from the command-line, as user, because under my builds of Linux, PulseAudio runs in user mode, both these modules seem to load fine, without my having to install any additional packages.
On more recent builds of Linux, one needs to install the package ‘pulseaudio-equalizer’ to obtain this feature, or some similarly-named package. But, because these two modules just loaded fine under Debian / Jessie, I guess the functionality once came integrated with PulseAudio.
But I soon started to run in to trouble with these modules, and discovered why, then, the equalizer function was not set up to run out-of-the-box…
(Updated 6/26/2020, 10h30… )
(As of 6/19/2020, 8h00: )
Even when these modules are loaded correctly, the user still needs some type of Graphical User Interface (‘GUI’) from which to adjust his or her equalizer (as shown above). The executable which opens this GUI is missing from the Debian / Jessie repositories, and can also not be installed through additional packages.
Now, I suppose that one reaction which I might have had, would have been, to install the graphical equalizer on my (more recent) Debian / Stretch computer, which I name ‘Phosphene’, and for which, the specific package is in the repositories. But the problem with that idea is the fact that ‘Phosphene’ has such a good speaker setup, that it does not need an equalizer. It was ‘Klystron’ that needed the equalizer, and that still has the older KDE 4 desktop manager!
Well, the executable which opens the GUI can be found here:
But, before the reader just jumps, and downloads that executable, and starts to try his or her equalizer, there is something that needs to be known.
If the lines have been added to the file ‘/etc/pulse/default.pa’, to load those two modules on start-up of the sound server, and if, after a reboot etc., the command ‘qpaeq’ is simply typed in, the user may see an error message, telling him that the executable that launches this GUI, cannot seem to establish a DBus connection to the sound server. Yet, if the user next verifies that the module ‘module-dbus-protocol’ has been loaded by the sound server, he may find that it has. And so, what gives?
Well, the problem which I ran in to for quite some time myself was that, when I tried to have this module load automatically, it was the module, and not the executable, that was unable to establish a DBus connection. I’ve run in to this sort of problem before. What I discovered was, that startup scripts on that build of Linux tend to run outside the DBus environment, and that the command to load this module, needs to be given by a user-action. (:1)
To make matters worse, if a second command is ever given to load this module, even if the first instance has been unloaded, doing so will actually crash the sound server! So, I guess I did find out why, seemingly at the last minute, this feature was dropped from Debian / Jessie.
Also, if PulseAudio has in fact crashed, even though it does restart automatically, it will end up not showing up in the (KDE / Plasma) Settings Panel correctly – a known problem which, under KDE 4, can be resolved by giving the following command once from the command-line:
But, this setback did not stop me. What I finally ended up adding to the file ‘/etc/pulse/default.pa’, were the following two lines:
load-module module-equalizer-sink #load-module module-dbus-protocol
That’s right; I left the second module commented out.
(Update 6/26/2020, 10h30: )
Then, I created the following script, which I just click on, in order to launch my graphical equalizer in a reliable way:
#!/bin/bash if [ `pactl list modules | grep 'dbus-protocol' | wc -l` == '0' ] ; then /usr/bin/pulseaudio --kill sleep 10 pactl load-module module-dbus-protocol /usr/bin/start-pulseaudio-kde fi qpaeq
One question which the reader might wonder about could be, why I did not use a full path-name for the ‘qpaeq’ command, which I gave instructions above, on how to download. And the reason why is the fact that, while I have copied that Python script to ‘/usr/local/bin’ (and set its permissions to executable), other users – my readers – may have this command installed under, or copied to, ‘/usr/bin’ instead. The reader may adapt this as desired.
What this little script does is, to load the module once, the first time the command is given – the script is clicked on – to open the equalizer, but then, never to load it again, because it has been loaded once successfully.
The result is that I can click on this script as often as I like, and the equalizer will open each time, and I get no error messages.
There is one more detail for me to comment on. As soon as the equalizer module is loaded, what it does is, to create a new, highly configurable ‘sink’. This means that the equalizer will appear as ‘a separate output’, which is itself configured to send output to another, ALSA output. First of all, if that ALSA output is busy, then the strategy won’t work. And secondly, in order for their sound to be equalized, applications will need to be instructed, to send their sound to this equalizer, instead of to the default sound output, which they’d normally send their sound to.
One way to solve that problem could be, to Open the Pulse Audio Volume Control, and to switch the output for one application from there. But then, a recurring problem will be, that the sound-output will often just switch back to the default, instead of to this equalizer. And so, what I found was, that the following solution works better for me:
From the KDE or the Plasma Settings Panel, the order of preference of the available outputs can be changed, and the entry for the equalizer, which begins with ‘FFT based…’ can be ‘moved up’, until it appears before the physical sound outputs, after which this reconfiguration can be saved.
I suppose that this configuration might also be customized for all the other categories of sound-generating applications. But I really just wanted the equalizer to be used, for when I am listening to music. So, I am also spared any need to configure this, for all the other categories of sound output.
(Update 6/19/2020, 9h45: )
The way my usage pattern normally goes, with Linux-based computers, during several years of ‘normal use’, I find no reason to reconfigure ‘PulseAudio’ in any way, and simply remain thankful that what it has to offer, works out-of-the-box. But after that many years, I do sometimes find a reason to start reconfiguring PulseAudio. When that happens, restarts of the sound server start to become frequent, and the situation described above also becomes frequent, that after a sound-sever restart, the devices are not listed in the (KDE-4 / Plasma) Settings Panel. There is usually a single command, which KDE-4 or Plasma give when a user starts a new session, and which connects the PulseAudio server to the Settings Panel. This does not come from within ‘/etc/pulse/default.pa’, which does get reloaded automatically, just due to the server restart.
But, even once I have found what that command is:
- I’ll want to be able to give that command quickly and painlessly, to avoid having to log out and back in again, or, to avoid having to reboot. And,
- Once I have a script lying around which I can just click on, I get nervous about the possibility, that I might click on that accidentally, and that, to have run the command more than once within any one server session, might actually misconfigure the same server session.
So what I also do is, to insert a simple test into the same bash script, for whether the command actually needs to be given, before giving it only for the one time it is needed. In the case of KDE-4, this is the script which performs the desired function:
#!/bin/bash # Warning: # This script is ONLY to be used with the # (Deprecated) KDE-4 Desktop Manager... if [ `pactl list modules | grep 'device-manager' | wc -l` == '0' ] ; then /usr/bin/start-pulseaudio-kde fi exit 0
I can just click on that at any time, and the worst that happens is, that the little launcher-icon bobs up and down for a few seconds, because no application window was opened. Yet, after the sound-server has restarted, clicking on this for the first time will also cause the Audio Devices List to become visible in the KDE-4 Settings Panel again.
I have a similar script for Plasma 5, but they are not compatible.
(Update 6/19/2020, 17h10: )
The statement that I just gave, about startup scripts and the DBus daemon, was a bit of a simplification. In reality, Linux computers have more than one way, for a user to run his or her own script, under their own username, but during startup. What I failed to do, would have been to add this ‘pactl load-module…’ command as a .desktop File, to a folder from which KDE-4 or Plasma 5 more-properly run actions on a session start.
What I did was, to try to inject this command, to load the module, into one script, that already gets executed separately, by KDE-4. The result was that again, the PulseAudio server reported the module as loaded, but that the Python script could not obtain a DBus connection to it.
- After that, I simply saved a lot of time, by adding this user command directly to the script, that just opens the equalizer settings.
AFAIK, When running ‘scripts’, KDE-4 and Plasma 5 have as their priority, to run those relatively early during a session start, in some cases so that the rest of the session even imports environment variables set in the scripts.
- Yet, By the time KDE or Plasma get to running .desktop Files, it should be possible to insert as a command:
Exec=dbus-launch pactl load-module module-dbus-protocol
(Update 6/26/2020, 10h30… )
Some of this thinking has become invalid, because while the PulseAudio daemon is a process, the modules it loads are not processes. In other words, whether or not the process inherits its DBus status, is independent, of later commands for that process to load modules…
(Updated 6/20/2020, 11h25.)
If using the GUI, one leaves out the ‘Exec=’ part. (:2)
The only observation about this, yields the facts that:
- The PulseAudio server itself cannot be launched using ‘dbus-launch’. Yet,
- According to the observations I’ve made in recent days,
when the ‘pactl’ command is given, its inclusion into the environment of the DBus session transfers to the PulseAudio server – or, to the one module.
Whichever method gets used to introduce this into the real-world behaviour of the PulseAudio daemon, will constitute bad practices in software design. And such a flag, of being ‘a bad practice’, can be enough of a reason for Debian Maintainers to avoid doing it.
(Update 6/20/2020, 11h05: )
Under KDE-4, the following panel can be found, within the Settings Panel:
Because KDE-4 is deprecated, I’m including a screen-shot, of the corresponding Settings Panel, under Plasma 5:
These Settings Panels are designed, so that IF the user clicks on “Add Program” (in this case, not, “
Add Script“), a dialog opens, in which the user may enter a command-line, so that this Settings Panel module will auto-generate a .desktop File as described above, as a hypothetical option, and spare the user the need, actually to edit his own .desktop File with a text editor. And then, the Settings Panel module will also place that auto-generated .desktop File in the correct (hidden) folder, to be run automatically on a session-start.
I don’t like using this feature, mainly because, once a user has discovered that he or she has made some sort of mistake, the GUI tends to become buggy, and actual attempts to edit the auto-generated .desktop File end up borking the files present in that hidden folder. If that point is reached, what the user will need to do next is:
- Find out which folder either version of KDE stores its .desktop Files in,
- Delete the misconfigured .desktop File manually,
- Start all over again…
So, unless a user can be sure, that he or she will always get the command right, that the new .desktop File is supposed to run, on the first try, this GUI is less useful than the Debian Maintainers hoped it would be.
(Update 6/20/2020, 12h45: )
Another observation I’d want to add is that, apparently, this need to perform a ‘dbus-launch’ of programs within a .desktop File, seems less urgent on Debian 9 / Stretch and higher, than it was on Debian 8 / Jessie. The reason I have, to think so, is the behaviour of my ‘Dropbox’ client:
- Under a Debian 8 / Jessie system, the launching of this service without ‘dbus-launch’, seems to cause a malfunction, while,
- Under my Debian 9 / Stretch system, the launching of this service without ‘dbus-launch’, seems to create no issues or malfunctions.
Therefore, the problem which I ran in to, getting the equalizer to work, may also have cleared itself up, by the time the Debian 9 / Stretch implementation came along, without any maintainer ever having discovered, what the problem seemed to be, under Debian 8 / Jessie…
(Update 6/20/2020, 14h40: )
One of the facts which I recently observed about my Debian 9 / Stretch computer was, that after Dropbox created a minor upgrade to itself in user-space, the corresponding line in the .desktop File had actually become:
Exec=Exec=dropbox start -i
Well, the reason why this would have happened would not be, that somebody was just asleep in front of the computer one night. The reason this would happen is, that a programmer was using an API to install the .desktop File, but that somehow, the programmer thought that he needed to give the ‘Exec=’ prefix to this API, when in fact the API adds it automatically. In this case, such an error can cause Plasma 5 to ignore the resulting .desktop File.