Beginning a GNU/Linux/JACK headless performance system

Hey all, I’ve been experimenting with dsp programming/audio-effects which is all code that exists outside of my usual sampler-sequencer performance stuffs (candor). I’m a Linux user and like most music-focused users of the operating system, generally each piece of software I use is a client of the JACK server which allows easy manual routing between the sound card and each client’s input/outputs. Since managing multiple dsp/effects-purposed JACK clients I’ve been performing a lot of internal channel routing between my programs. Not a fan of looking at my computer screen when making music, I’m really happy with a method that I use to boot my computer / network my performance software in real-time and I thought I’d share it.

Today, autocable’s public repo has been updated with code to allow piped input and connect/disconnect. While these are trivial changes, piped input makes it really easy to script connections between JACK clients and your sound card on the command line.

Using qjackctl, a gui frontend for JACK, an empty connection graph with a sound card and two clients looks like this:

Then we run:

$ echo "connect system:capture_1 candor:in_2
> connect system:capture_2 candor:in_4
> connect candor:out_1 cyperus_osc_test:in_1
> connect cyperus_osc_test:out_1 system:playback_1
> " | ./autocable

We see connections made:

To disconnect connections, simply use ‘disconnect’ instead of ‘connect’:

$ echo "disconnect system:capture_1 candor:in_2
> disconnect system:capture_2 candor:in_4
> disconnect candor:out_1 cyperus_osc_test:in_1
> disconnect cyperus_osc_test:out_1 system:playback_1
> " | ./autocable

All connections we made are undone:

Now that we’re allowed to automate JACK connections, it’s easy to put these instructions in a startup script so the computer can do it on its own. There are a few different places where code is automatically executed on Linux systems. For example if your GNOME/Cinammon/Xfce/KDE/Unity auto-logs in, you could place the contents of your script in “/home/ < YOUR_USER > /.xinitrc”. If your computer only auto-logs into bash for you, maybe use “~/.bash_profile”, “~/.bash_login”, and “~/.profile” (files executed in that order).

Let’s say our computer auto-logs our user into bash and we’ve chosen “~/.bash_login” to run the instructions. Something like this would work:

tmux new -d -s monome 'serialoscd'
tmux new -d -s jackd 'jackd -d alsa' 
sleep 3
tmux new -d -s candor '~/DEV/candor/candor' # jack client 1
sleep 3
tmux new -d -s test_osc '~/DEV/cyperus/test_osc' # jack client 2
sleep 2
echo  -e "connect system:capture_1 candor:in_2
connect system:capture_2 candor:in_4   
connect candor:out_1 cyperus_osc_test:in_1
connect cyperus_osc_test:out_1 system:playback_1
connect cyperus_osc_test:out_1 system:playback_2
" | ~/DEV/autocable/autocable

Running these instructions will setup intended programs in the correct order for this example (I like to use tmux to launch daemon applications as it avoids the pitfalls of ampersand operators and sleeps in bash).

The sleeps are to wait for application setup (can’t network clients that don’t exist yet).
A script like this could be paired with an arduino or another similar device to provide some kind of indicator (LED) that setup has finished completely.

Hope this was interesting and/or useful!


Very cool. Presumably you could start up all your audio daemons with systemd or something instead of relying on tmux :smile:

1 Like

this is so good to see, thank you.

and candor looks fantastic! exceptional documentation.

could you quickly describe your linux build and any optimizations you’ve done to the environment? what sound card are you using? or that’s asking quite a bit-- perhaps you have some links to good resources on getting a smoothly-running linux audio setup?

Thank you!

I’m using a pretty simple setup. For my host OS I’m running a vanilla Gentoo Linux install. The only optimized part of my environment is a manually configured 4.0.5 kernel with these audio-intended config settings:


Then I have ALSA and JACK installed. A similar kernel config on any Linux distro with ALSA and JACK should be enough to get started. With some experience, I’ve found that building the true real-time kernel patches on a competent desktop or laptop machine isn’t really necessary. Although it’s different for embedded or slower machines.

A great resource on this is the linux audio system configuration wiki. There’s this really useful perl script there which will advise you of changes you can make to your current system to make it “more real-time”. Grab it with git:

git clone git://
cd realtimeconfigquickscan
perl ./

For an audio interface I’m currently using the Presonus AudioBox 1818VSL over usb2. I’ve also used the really great Roland UA-25EX and Echo Layla 24 with no problems. Although for the Presonus, I had to downgrade my laptop’s usb3 ports to usb2 in the bios (not Linux’s fault).

Good, miscellaneous articles for ALSA and JACK configuration on different distributions:


VERY cool stuff, murray, thank you!
hey, has anyone tried running this on a raspberry pi with a usb-audio interface?
I’m wondering if performance is good enough for two channels, would be neat to see a standalone monome with a raspi tucked away inside… i’m new to the community, so this probably has already happened… :sweat_smile:

Thanks! I’ve run Jack on my Beaglebone Black with a two-channel usb interface (the UA-25EX mentioned above) , but not with this startup method. Here’s another linuxaudio wiki on Raspberry Pi and realtime, low-latency audio with respository and JACK setup closer to the bottom. I’m sure what you suggest is totally possible.


i’m having the most fun time just trying to get jack running on the r-pi. only minor hiccups installing serialosc but it went quite well.

now just trying to test sound with supercollider, working from:

jackd -p32 -dalsa -dhw:0,0 -p1024 -n3 -s

just throws an error:

Failed to acquire device name : Audio0 error : Invalid argument
Audio device hw:0,0 cannot be acquired...
Cannot initialize driver
JackServer::Open failed with -1
Failed to open server

which is a stumbling block to even knowing if SC is working (server won’t boot, as is)

any wise words from smart linux people? i’m working on getting together a tutorial on this stuff to lower the barrier for potential r-pi grid programmers…

edit. the issue is likely this which i didn’t put in the debug above:

Failed to connect to session bus for device reservation
Unable to autolaunch a dbus-daemon without a $DISPLAY for X11

as i read somewhere that the driver isn’t on unless X is running?? my goal (and only way) to do this stuff is headless via ssh.

my confidence in the platform is wavering, but so if my confidence in my linux knowledge.

1 Like

Did some searching and I found [[LAU] Solution for jackd2 and dbus without X session][1]. He sets an environment variable… looks like the gdm provides dbus connection, but without it one must be set manually?

The solution was to set the session bus address variable to the path
to that dbus-daemon’s socket, like so:
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket

I don’t have a RasPi to test, but hopefully you have luck with this


Have you seen this:

i hadn’t seen this link specifically but it looks similar to most tutorials-- i’ll try this dummy method of running jack and see how it treats the dbus/etc.

i was looking for a quick out-of-the-box sc installation but it’s become clear that i’ll need to do some deeper optimizing.

having dbus be always-on in jack2 has been a major pain for me. if you can find a jack1 package that should shore things up.

1 Like

sticking with jack1 is no longer an option with the latest faust from git - found my way back to lines googling error messages! However the dbus fix above does not work for me now…

On a recent arch install (raspberry pi3) you may find (as I did) it’s necessary to recompile & install jack2 without dbus support in order to run headless. base-path defaults to /usr/local - so you can either configure jack2 with different options, or accept the default /usr/local, then modify your arch system to also search /usr/local:

echo ‘/usr/local/lib’ > /etc/

I prefer this one, so it’s obvious which things have been compiled/installed outside of arch’s build system…

@ioflow @rick_monster and anyone interested: I’ve connected my main audio interface (a Presonus 1818VSL) to the Raspberry Pi 3 and was able to get unpatched Jack2 running. I attempted to run my monome application candor, but it segfaulted so I defaulted to a simple jack client (jacksandbox ) which compiled and ran fine. The following steps assume you’ve installed Jack2 on your Debian-Raspbian system, I’m fairly certain these steps will work on other distributions:

First, if you’re using an i2s soundcard, you’ll want to add the i2s-mmap overlay to your ‘/boot/config.txt’. Save it:


Second, use aplay to list your soundcards:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 1: VSL [AudioBox 1818 VSL], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

Then, based on which card you want to use, add an entry for that card in your dbus’ “/etc/dbus-1/system.conf”. Replace the ‘1’ at the end of the line with your intended ‘card’ number between the “<busconfig>” tags:

      <policy user="pi">
        <allow own="org.freedesktop.ReserveDevice1.Audio1"/>

And then append this to the end of your “~/.bashrc”:

export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket

Save and restart your Raspberry Pi. Here’s an example of a call to jackd, you can append the “-D” once you’ve settled on a configuration and observe a clean output:

/usr/bin/jackd -dalsa -r44100 -p1024 -n2 -Chw:VSL -Phw:VSL --midi raw

To interact with my ALSA/JACK system over SSH, I’ve installed Python and the JACK-Client module which I used to test my audio connections between clients. Good luck (I’ll update this thread as I experiment further and progress towards a more stable system)!


are you using linux RT-preempt? I had a nightmare last week getting repeatedly mangled on a systemd bug, which was triggered by my linux-rt build…

Kind of thinking seriously at this stage about going back to slack but yea those steps all look familiar - we should really try to club together on here & produce a linux distro something like the old dynebolic but tailored to raspberry pi3, otherwise many others are just gonna be duplicating this same effort. I don’t know how to approach that!

1 Like

Have you considered going with buildroot instead of a distro? It would be more like having a firmware for the Pi rather than an editable OS. AFAIK you can have a readonly rootfs and then mount the SD card for any RW you need.


I am not using linux RT-preempt, I generally keep my kernels stock until I have a reason to patch (which I may have run into). I would love to put together a Raspbian or even ‘embedded linux music performance’ image. I think the desktop is covered with distro’s for multimedia, but maybe something more stripped down and streamlined would be useful.

1 Like

Yeah, I fooled around with buildroot while poking around the AD Blackfin. I think that’s a great idea once a set configuration or selection of applications has been chosen.

I’m currently starting jackd on my pisound box using JACK_NO_AUDIO_RESERVATION` environment variable, which is a bit shorter than fiddling with dbus. Jack just doesn’t try to reserve the sound board and doesn’t seem to mind the missing dbus session daemon.


Nice, I’m going to give this a try tomorrow!

For those interested, here’s the relevant pull request that describes what this does

1 Like

Has anyone tried/started making candor work on a 128? Thinking about UI for stripped-down version?