Another Reason, for me Not To Set Up JACK as the Back-End For PulseAudio

According to This Posting, I had written that hypothetically, it might make some sense for me to set up ‘JACK‘ as the back-end, by which ‘PulseAudio‘ sends its sound output, full-time. As opposed to the notion not making sense, to allow a few scripts to do so temporarily, that are being run by the ‘QJackCtl‘ GUI.

Well there is still a reason, why this might not be so. Doing so would be consistent, with setting up a Debian system completely according to our own preferences, and then if something does not work, we are up to our own devices to fix it.

My laptop ‘Klystron’ is a Kanotix / Spitfire system, which is also Debian-based, but in which the exact configuration has been done for me, by the Kanotix team, from their Live Disk (which can actually be written onto a USB-Key). This means that there is an advantage to me, in keeping certain configuration details conform to what the Kanotix people prescribed. If I did run into trouble with it, they would have some chance of maybe suggesting solutions, but only on the assumption that mine is still functioning within their parameters.

The way those parameters are, the current back-end to the PulseAudio sound server is displayed in the GUI as being “gstreamer“, and yet good compatibility with all things ALSA is maintained…

If I was to reconfigure my computers completely, for example because I wanted to change them to use the ‘GNOME desktop manager’ for instance, instead of ‘KDE‘, then the Kanotix team would say ‘Sorry, we are not familiar with the details of your system anymore. Therefore, we cannot help you.’

Yet, more generally, Debian allows deep changes to a configuration.


BTW: On the computer I name ‘Phoenix’, which also acts as my Web-server, all I did was to change the speaker-configuration, from a Legacy Stereo output, to a 4-channel output, on the assumption that by now, software running on the computer is better-able to produce surround-sound, than the Dolby Amplifier was, which I bought in the 1990s, and which AFAIK only offers ‘Pro-Logic 1′. According to this thought, the actual software offers better-than-Pro-Logic-1, and the same old amp is able to accept 4 independent analog inputs, as one of its modes.

Well, making this configuration change was easy, and accessible through the GUI, without having to specify that we would want to use a different actual output device, let alone specifying a different back-end. Hence, according to this GUI, the back-end is still written as “gstreamer“.

But just because I had selected a new speaker arrangement from a drop-down list, of what my current output device already offered, PulseAudio was unstable until I did a reboot.

In fact, a general way to reset PulseAudio, is to give the command

pulseaudio -k

This tells the current PulseAudio server to die, and then on my box, KDE promptly launches a new instance. Well, after I have done so, my sound still plays – with the new settings. But instead of seeing the devices list I am used to, I next only see “PulseAudio Server” as the available devices. This is what gets reset, when I next do the reboot.

So I can test the new configuration without doing a reboot, because the configuration has been chosen and – usually – works. But then in order to get the GUI to display correctly again, I need a reboot.

Further, on the laptop I name ‘Klystron’, it was important to me that ‘QJackCtl‘ be able to start JACK and not show its native message window necessarily, so as not to confuse a hypothetical other user.

In place of that message window, the default configuration of QJackCtl supplied by me has now been updated, to show a ‘kwrite‘ application window as part of its pre- Start-up script, which will give a user a warning, to know that regular sound output is being suspended until they stop JACK again from that GUI, as well as to tell the user what JACK is, and which applications require it…

The actual text file kwrite displays, as well as the kwrite application itself, all have non-user locations in my (root) file system, so that they can also be named in the configuration file as such. I like to place that sort of stuff somewhere under ‘/opt‘, such as in ‘/opt/misc‘.

I think that my message window is less threatening in tone to some, than logs of MIDI events, and logs of connection / disconnection activity…


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>