Rack on Linux with relatively old hardware: a personal update

TL;DR: Linux user here. In some instances, -at least on my system- VCV Rack may perform better on Alsa than on Jack. Maybe give it a try if you haven’t. YMMV.

I thought sharing my current status could help other Rack users on Linux, so…

Distro: Kubuntu 20.04.1 LTS, kernel: 5.4.0-42-lowlatency #46-Ubuntu SMP PREEMPT, GPU: Nvidia GTX260 with nvidia-340 drivers, CPU: i5 660 3.33GHz, RAM: 4GB (…), soundcard: Focusrite 2i2. As you can see, this is suboptimal/obsolete hardware, and maybe it is causing some of my issues, but that’s how it is.

After many attempts at optimizing my system for Rack while using Jack as audio driver -which in short, mostly resulted in various frustrations- I gave another try at Alsa (which I had tried in the past, on Ubuntu 18.04 and before many other changes to my system, with unsatisfying performances).

Performances: surprisingly (for me) Alsa turns out to be much more efficient than Jack, at least when it comes at the number of modules I can add to a patch before I get xruns and clicks.

MIDI: last time I tried using MIDI for sequencing external hardware, everything was extremely crashy (please let me word it this way. I’d be precise if this was a bug report, which is not), so right now I’m only sending a clock via USB to a drum machine, which in turns clocks my other hardware. It’s not 100% precise but it seems to work.

I’m going to do more finetuning - maybe by removing some of my “optimizations” I can get rid of those crashes without affecting the performances.

UPDATE: some time and some system upgrades later, this reversed and I’m now using Jack.

Well, it’s not jack instead of ALSA…Jack runs on top of ALSA, and as such is using some extra CPU and RAM that is instead available for VCV when you use ALSA directly.

super weird

have you set your computer to use jack (adding you user to the audio group, enabling the RT,etc? ) it happened to me when I have no added my user to the audio group

try run qjackctl and check the message status

I should have amended this post. What I described above happened after a system upgrade and lasted for some time. At some point the situation reversed and I’m currently using Jack. It’s annoying that some other applications don’t support it and require to stop jackd, but I’m happy with Rack performances. I think I’ve tried everything multiple times, included and not limited to your guide (thanks for it btw!).

1 Like

You shouldn’t need to stop jack at all.

  • Install pulseaudio-module-jack

  • Open /etc/pulse/default.pa (or ~/.config/pulse/default.pa if you want to set it for your user)

  • Add the following lines, underneath the line that says #load-module module-alsa-sink:

load-module module-jackdbus-detect channels=2
  • Restart pulseaudio or logout and it should now be permanently bridged to jack.
2 Likes

Thanks @TroubledMind, I was missing those two lines, now it seems to work as expected.

1 Like

Agree with the above, but I’d like to point out that on relatively recent distributions the above happens auto-magically, requiring no manual input. This is from an up-to-date Arch machine, unedited:

### Automatically connect sink and source if JACK server is present
.ifexists module-jackdbus-detect.so
.nofail
load-module module-jackdbus-detect channels=2
.fail
.endif

I run Gnome, and I find the most important thing to get right in getting Jack and Pulse to play correctly is to make sure that the desktop is using the bridge:

If it is set otherwise (like pointing to the interface directly) they won’t interoperate well.

The one annoyance is volume: the multi-media key/desktop volume controls will control the things going through the jack sink (bridge), but not things (like rack) that go to jack directly. That’s not really an issue usually because my speakers themselves have a volume control, but if, say, I’m using headphones (which annoyingly must by plugged in before Jack starts – may as well reboot if you forget) then I have to use alsamixer directly to control that volume.