Jackd dies after a few seconds on playback on Arch Linux

I’ve successfully setup SC on Ubuntu and Fedora, but on Arch (which I wanted to try because it comes with Qt 5.15, which I’m hoping would solve some wayland bugs) I’m having some jackd issues.

Basically, SC plays for a few seconds (some totally basic Synth(\default) output) but then it auto-kills jackd without any other user invention and posts this:

JackDriver: killed by jack
Server 'localhost' exited with exit code 0.
server 'localhost' disconnected shared memory interface

The longest I’ve managed to run a Synth is about one minute, it usually dies much faster, in about 10-15 seconds.

Any ideas what could be causing this?

Also, while it playes, the CPU usage is substantially higher than on the other distros, about 10% for just that synth. The latter might have something to do with the fact that jackd refused to work on Arch without me following its demands and setting

Please check your /etc/security/limits.conf for the following line
and correct/add it if necessary:
  @audio          -       rtprio          99

And desipte that, I see with qjackclt a ton of xruns, which seem to explain the quit as well

subgraph starting at SuperCollider timed out (subgraph_wait_fd=9, status = 0, state = Running, pollret = 0 revents = 0x0)
internal poll failure reading response from client SuperCollider to a xrun event
**** alsa_pcm: xrun of at least 0.201 msecs
23:41:47.675 JACK connection graph change.
23:41:47.877 JACK connection change.
23:42:12.645 XRUN callback (150).
delay of 23605.000 usecs exceeds estimated spare time of 21228.000; restart ...
**** alsa_pcm: xrun of at least 0.455 msecs
23:42:14.340 XRUN callback (1 skipped).
23:43:15.288 XRUN callback (152).
delay of 21880.000 usecs exceeds estimated spare time of 21289.000; restart ...
**** alsa_pcm: xrun of at least 0.106 msecs
23:43:16.972 XRUN callback (1 skipped).
23:44:48.713 XRUN callback (154).
delay of 22506.000 usecs exceeds estimated spare time of 21258.000; restart ...
**** alsa_pcm: xrun of at least 0.177 msecs
23:44:49.923 XRUN callback (1 skipped).
23:45:01.917 XRUN callback (156).
delay of 22705.000 usecs exceeds estimated spare time of 21317.000; restart ...
**** alsa_pcm: xrun of at least 0.120 msecs
23:45:02.118 XRUN callback (1 skipped).
23:45:08.778 XRUN callback (158).
delay of 30736.000 usecs exceeds estimated spare time of 21316.000; restart ...
**** alsa_pcm: xrun of at least 0.374 msecs
23:45:10.191 XRUN callback (1 skipped).

Any ideas how to fix this? I’m getting no xruns on Ubuntu or Fedora… (I haven’t actually got to enabling wayland on Arch, so that’s unrelated to this jackd issue.)

Also, I have jack not jack2 installed on Arch, if that makes any difference… I suspect that’s the problem though. Ubuntu has separate packages but only installed jack2 for me. Fedora calls it jack-audio-connection-kit, but that’s actually jack2 given the version (1.9.14); jack1 has some version 0.125. From their FAQ:

So what about the version numbers ? Jack 1 approaches version 1.0. At the time of writing it is at version 0.121.3. Jack 2 approaches version 2.0 - at the time of writing it is at version 1.9.10. run jackd --version to find out the version that you have installed.

The trouble is that pacman wants to remove 259 packages on Arch to get rid of jack (1)… which seems a bit much…

Well, the solution was rather trivial; just installing jack2 prompted for

resolving dependencies...
looking for conflicting packages...
:: jack2 and jack are in conflict. Remove jack? [y/N] y

I got not more auto-quits with jack2 in SC and cpu usage with just one synth is around 2%… but qjackctl can’t seem to display anything now about the status messages, even after restarting it… (unlike what it does in Fedora or Ubuntu.) I guess it got hooked on jack1, probably with some config file.

It’s a remote experience with qjackctl but when I was trying to compile it on macos I noticed that it links (?) directly to jack. So it seems to be it needs to be recompiled against jack2 to work with jack2. I’d guess there could be a separate package with qjackctl for jack2, but I’m not sure.
Also, I might be completely wrong here :slight_smile:

m

Well qjackctl works with jack2 after a reboot. I’m not sure why didn’t before since even KDE, which I was using, doesn’t do MS Windows style full image prefeching (I’m talking about MS .pf files), as far as I know. I’m pretty sure ldconfig ran when I installed jack2 since SC picked it up without rebooting.

Or actually it doesn’t quite work. On the other distros qjackclt picks up the jack (2) instance started by scsynth, i.e. the play & stop buttons automagically change status. And it actually did this with jack1 on Arch too. But if I do manage to create some xruns (compiling something while sc plays), it does show them in the messages window, even if it thinks that jack’s not running. The startup messages are bit confusing

09:13:24.602 Statistics reset.
09:13:24.644 ALSA connection change.
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
09:13:24.666 ALSA connection graph change.

The 2nd graph change actually means it can receive xrun info now, even though it doesn’t quite detect that jack was started, only that the ALSA graph changed.

Actually, I misrembered how it worked on Ubunutu. There it can’t pick up the jack2 changes either.

09:32:15.843 Statistics reset.
09:32:15.954 ALSA connection change.
09:32:16.136 D-BUS: Service is available (org.jackaudio.service aka jackdbus).
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
09:32:16.185 ALSA connection graph change.

Only on Fedora it works properly out of the box.

09:54:32.156 Statistics reset.
09:54:32.188 ALSA connection change.
09:54:32.247 JACK connection change.
09:54:32.264 Client activated.
09:54:32.265 Patchbay deactivated.

And oddly it’s not because of D-Bus settings in qjackctl. It’s actually off in the Fedora qjackctl settings (as is in Arch). D-Bus is actually on in the qjackctl setting in Ubuntu, but that doesn’t help it… So something else is responsible for the difference.