On the laptop I name ‘Klystron’, the default sound server is PulseAudio, as is often the case with desktop setups. And yet I found myself installing a lot of Linux music-authoring software on it, only to find that in order to get the full benefit of that, we need to be able to use JACK as our sound server. This was not really a new observation.
Specifically, in order to allow ‘Rosegarden‘ and ‘QTractor‘ to work fully, we need to have JACK. Without JACK installed, Rosegarden will complain when run that it can produce no sound output, but is still installable. And QTractor has the actual JACK daemon as one of its install dependencies. More generally, I did not find any DSSI hosts, that could run without JACK.
Under Linux, ‘LADSPA’ and ‘LV2′ are effect-plugin-APIs, which can also be used from applications such as ‘Audacity‘, while ‘DSSI’ is The Linux instrument plugin-API. One needs DSSI for any type of plugin, which receives a MIDI sequence and plays that, regardless of whether the MIDI-sequence came from a sequencer, or from a live, real controller-instrument.
And so I took the time last night, to set up the actual JACK daemon – not just its libraries – to coexist peacefully with PulseAudio.
The approach I took, was to install QJackCtl, a GUI that allows the user to start and then stop JACK, and that allows the user to configure this starting and stopping to taste. In order for JACK to do what it is supposed to do, I needed to change the ‘Server Path’ with which QJackCtl launches the daemon, to
pasuspender -- jackd
This field within QJackCtl tells the GUI what command to execute, to launch JACK, and has recently been renamed to the “Server Prefix”. Nevertheless it can still be customized in this way.
‘pasuspender‘ is a utility that comes with PulseAudio, which tells this server to suspend its access to the sound devices, for as long as the program is running, which follows as its command-line parameter. The two dashes are important.
I found, that although ‘pasuspender‘ does suspend PulseAudio, it also fails to resume this service, once the program has terminated, that was given as its parameter. I suspect that this happens, because QJackCtl terminates the command
pasuspender -- jackd
instead of actually terminating the child-process
jackd
Thus, pasuspender cannot act on ‘jackd‘ having exited, because the parent process was terminated, right along with the child-process. And so there is another field within QJackCtl, where I get to specify a post-shutdown script for JACK, where I simply inserted the command
pasuspender /bin/true
This second invocation of ‘pasuspender‘ exits without error, and actually causes PulseAudio to resume.
It is important to give this command in the correct field. I.e., If we gave this command in the pre-shutdown field, we would get a mess.
Now, this is a configuration which allows me marginal use of JACK, and while I have QJackCtl running, PulseAudio will just not work. There exist some script-artists, which will go further, and who have written more-complex scripts for QJackCtl to execute, and that will insert JACK as a back-end, for PulseAudio to continue sending sound-output to, once JACK has been launched. And then those scripts will also reverse this setup, and set PulseAudio back to running in its default mode, once JACK has been terminated.
I had two reasons not to go this route.
- On my systems, the back-end which
PulseAudiouses are fragile. While they can be reconfigured, doing so messes up thePulseAudioinstance running, until my machines are rebooted again. Changing this configuration within a session is poorly advised, on my setups. - Trying to do so struck me as somewhat ambitious, and there are many ways in which an attempt can get stuck, due to minor logical errors between the scripts. The fact that I needed to execute
pasuspender /bin/true
at shutdown, to get PulseAudio truly working again, reminded me that unexpected logic glitches can come up, and that maybe I should not try to get JACK and PulseAudio working concurrently, part of the time. If this was a full-time setup, this option might actually make sense, but for temporary use – controlled with some scripts – this option seemed to make little sense to me.
The only possibility which I need to worry about now, is that I might lend this laptop to some friend – or even to a girlfriend in the future – but that this other person might not know, that she is supposed to start JACK using QJackCtl, before running QTractor. QTractor, being a package that had the JACK daemon as an install-dependency, would detect that ‘jackd‘ is not running, and might try to take matters into its own hands then, thus launching ‘jackd‘, without ‘pasuspender‘.
Some other user would need to be warned, against allowing this to happen.
But, as long as I did launch ‘jackd‘ through QJackCtl first, QTractor also runs fine – according to extensive testing which I did last night. And then according to that, terminating JACK still returned control to PulseAudio gracefully.
In order perhaps to ease such a hypothetical scenario into working, I did a basic, minimalist, working configuration of QJackCtl, and then copied its configuration file
~/.config/rncbc.org/QjackCtl.conf
into the root-folder ‘/etc/skel‘.
What this means, is that whenever I create a new user in the future, that is not a system user but a real person-user, this configuration file will also get copied from ‘/etc/skel‘ into the newly-created home directory, where sundry other initial files get placed.
And this should mean, that when such an other person first launches QJackCtl, this program will already be set up to work according to the hardware that my laptop has to offer, and the other person will only need to click on the ‘Start’ button to start JACK.
But the other person would first need to know, that he or she needs to do so. And then one way for them to find out, is by ‘Rosegarden‘ displaying the message for example, that it will only offer limited use, until JACK is started. When a naive user looks at the K-Menu, QJackCtl is offered as The Obvious Way to launch JACK…
Dirk
BTW, When the reader decides to install ‘jackd2‘, which is the up-to-date Debian / Jessie package for the actual daemon, on a version 4.4 kernel, please do yourself the favor in the configuration dialog, to select, to Enable users to run it in real-time mode. Because kernel version 4.4 offers some processes this ability, it should not be wasted, and JACK should not be wasted, by running in user-mode.
Selecting this option will add the real-time priority capability to users who belong to the ‘Audio’ group, and will require a reboot to take effect. But this is an advanced feature of such a high kernel version, that will also be well-worth the effort, and still allows the ‘jackd‘ process to run as a user-process, yet with real-time priority.
Further, my user-name is ‘dirk‘. Before I try to copy the basic configuration file ‘QjackCtl.conf‘ to ‘/etc/skel/.config/rncbc.org‘, I first run the check
cat QjackCtl.conf | grep dirk
If there is any output, this will mean that I have by now hard-coded a file into the configuration, such as maybe a Sound-Font, that is meant to be found in my personal home folder. I also know consciously that I never did so, as a precondition to proceeding.
And, If the goal is to set up a hypothetical, naive user to be able to start and stop JACK, as well as ‘FluidSynth‘ via the ‘QSynth‘ GUI application, then one should take into account, that such a user might get spooked if he sees either program display a message window, with detailed messages he or she does not understand. Whether the message window should be displayed, is part of the settings information, and the window can be hidden.
But, if either program outputs messages into their log that are deemed of a serious level, then the program will change the message window to Visible by itself.
Serious messages, according to the logic of these programs, include ~unable to lock memory~ and ~unable to achieve real-time status~ . The presence of either of these messages did not prevent me from using JACK as well as FluidSynth last night, the latter by way of QSynth. I got sound output.
But the mere presence of a message window, could distract our hypothetical, naive other user from continuing with their project, and getting to the point where they would actually test sound output. This is especially plausible, since many additional messages are sent to these windows, that are not serious in any way, but that can confuse the user.
Hence, to have configured ‘jackd2‘ for real-time priority, also helps the applications open with the default settings I assigned them, and not display a message window at all – and work.
(Edit 07/17/2016 : ) One risk which has bothered me for a few days, was that some user could launch a JACK-dependent client on the laptop ‘Klystron’, that would detect that JACK might not be running, and that such a client might try to launch JACK by itself, without going through ‘pasuspender‘.
One of the facts which might prevent this, is that ‘jackd‘ must always be launched with specific configuration details.
If we look at the Settings panel of the ‘QJackCtl‘ GUI, the 4th Tab is a “Miscellaneous” Tab, and one of its check-boxes states, whether the GUI application should store the JACK configuration to a file named ‘~/.jackdrc‘ . Because the GUI application itself stores its configuration details to ‘~/.config/rncbc.org/QjackCtl.conf‘ , this setting will cause it to store the more-standard configuration file ‘~/.jackdrc‘ with a matching configuration.
This more-generic file is where most programs will look, to find the user-specific details to launch JACK with, outside the GUI application. I feel that by un-checking this box within QJackCtl, and then deleting that file, I may be able to prohibit unauthorized launching of the daemon, from certain clients.
However, the settings in this Tab do not cause the Save button of the Settings panel to become active, unless we also change certain other settings in the same Tab. After that has been done however, the GUI application will ‘remember’ this setting – as well as the relevant JACK settings – from its own configuration file.
2 thoughts on “Running JACK side-by-side with PulseAudio”