## Running JACK side-by-side with PulseAudio

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 ‘pasuspenderdoes 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.

1. On my systems, the back-end which PulseAudio uses are fragile. While they can be reconfigured, doing so messes up the PulseAudio instance running, until my machines are rebooted again. Changing this configuration within a session is poorly advised, on my setups.
2. 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.