Linux+JACK Rack2 performance

VCV Rack
1

I’m using Ubuntu Studio 20.04. JACK is working well with SuperCollider, Reaper, Vital softsynth, Pure Data etc.

With Rack 1.1.6, I had entirely acceptable performance (and even integrated it into my SuperCollider live performance setup).

With Rack 2, I can make a patch with one VCO, one Bogaudio Mix4 and one Audio output module, and it’s glitching periodically (with xruns accumulating in qjackctl’s display).

I do find on this system that the built-in soundcard’s performance is terrible and USB soundcards fare better. Still, it’s a bit startling that one oscillator is too much for a system where I can run a full musical texture in SuperCollider, totally glitch free.

Anything I can do to bump the speed up?

hjh

2
3

Greetings ! I’m running v2 on a desktop box here, with an AMD FX6300 CPU. No problems running fairly large patches, though I’m thinking better results might be available with an updated Skrylar JACK module (which does not appear forthcoming any time soon). What are your JACK settings and hardware specs ? Also, are you running the official binary or your own build of VCV Rack ?

Btw, welcome to the group ! I know you and your work from the SC lists, nice to see you here. We’ll get your problem sorted out (I hope).

Best regards,

Dave Phillips

4

Also, how many threads have you set to use in Rack?

1 Like
5

44.1 kHz, I’ve tried buffers of 256 and 1024. 1024, the audio is cleaner (but still not guaranteed) – but this impairs timing of MIDI response, so I really need to run at 256 for production.

My JACK settings are more than adequate for fairly heavy SC usage, btw.

Official binary.

Thanks! Actually I’ve been using Rack in classes for a year+ now – FWIW never had many questions about it b/c it just works, generally.

Ah, I missed that setting. I’ll bump it up to 2, or maybe 4, and see how it goes.

hjh

6

I was going to say try taking it down to 1 if you had it higher. I used to run v1 at 8 all the time but the engine has changed now and for it works much better at 1.

7

I’ll second @TroubledMind’s advice. I’m getting good results with Rack 2 (better than I did with 1.6) on a fairly modest machine running Ubuntu Studio 21.04, using Jack with a buffer size of 512, 3 periods and a 48 kHz sample rate, and using a single thread in Rack. It feels like the best approach with Rack 2 may be to start at a single thread and only increase the number of threads if you need it (once a patch starts getting complex). Also: keep in mind that Rack 2.0.5 seems to have an issue with sample rates and Jack. You should be OK if you stick to 44.1 kHz but anything above that may not work. (I’m sticking to 2.0.4 for now.)

1 Like
8

Just for fun, a few figures (44.1 kHz, 1024 samples/period, 2 periods/buffer, reading average CPU percentage from qjackctl, not from Rack’s status bar):

| Config                      |   1 thread |  2 threads |
|-----------------------------+------------+------------|
| No audio apps               |   1.2-1.3% |   1.2-1.3% |
| Open Rack 2, no modules     |   1.1-1.4% | 0.27-0.33% |
| + Audio module --> "system" |   4.7-4.8% |   2.5-2.8% |
| + Bogaudio Mix4             |   5.9-6.0% |   2.8-3.2% |
| + Rack VCO                  | 10.9-11.0% |   3.9-4.8% |
| + 2nd Rack VCO              | 13.8-14.0% |   4.7-4.9% |
| + 3rd Rack VCO              | 15.5-15.6% |   5.4-5.6% |
| Delete all modules          |   1.2-1.3% | 0.31-0.35% |

Not shown in the table is that CPU spikes seem to be more severe with two threads, so, while the reported average may be lower, there might be a higher risk of xruns.

Rack 2 vs Rack 1, it’s hard to compare JACK CPU figures because Rack 1’s interaction with JACK was different (JACK would report lower than true CPU usage). All I can say is that, with the built-in soundcard, for me Rack 1 produces a stable signal except when adding modules, while Rack 2 sometimes glitches with a small number of modules and no activity in the interface.

Similar advice from two people – sounds convincing.

I guess I’ll just keep an eye on it. The glitching seems inconsistent – this morning, I heard a lot less glitching than yesterday – which is troubling for a live setup, if you don’t know from day to day how the performance will be. (But, in a live situation, I’m using a USB soundcard which seems to be more stable.)

I’m holding off on 2.0.5 until there’s some news about the sample rate problem.

hjh

9

2.0.6 is out: I haven’t done any extensive tests, but it looks like it solves the sample rate issue (along with a MIDI input crash issue i was experiencing).

2 Likes
10

I have found out that the only reliable way to have low latency audio on Linux with VCV is go directly with ALSA. The internal engine sample rate should be equal or factor of two to the sample rate of the audio interface. Also real time scheduling should be enabled (see limits.conf). Regarding threads in my case on aarch64 (Rasberry Pi 4) - each thread needs 1024 sample buffer - otherwise it starts glitching. So for example if I need 2 threads - I will have to go for 20 ms latency. I have found that Jack is generally not stable and low latency enough for me - it is an additional layer over ALSA anyway. For live use with Linux and VCV 2.x - the only way to go is real time ALSA + single thread.

11

Jack is not adding latency to your audio framework, even when it run over ALSA

12

Not gonna argue. I am just saying what works for me. Using VCV + Jack with all possible tricks that you can think of so far has been bad experience for me for live performances. I only get satisfactory results when using plain ALSA. And I need at most 5 ms latency otherwise playing keys becomes laggy.

14

To make sure others aren’t confused, JACK doesn’t add latency, if it has then you’ll want to look at your JACK configuration.

2 Likes
15

That is NOT what the post says! It says that using Jack and normal buffer sizes (256) gives glitches, and the only way OP can get rid of the glitches is to increase the buffer size. No one here is saying that Jack is inherently increasing latency.

1 Like
17

So I asked on IRC and was advised “vcvrack just uses rtaudio and rtmidi which dont work well in jack”.

18

Exactly. This sums up my experience. So to keep this clear: if anybody wants to use VCV as a live instrument on Linux - ALSA with RT priority and a single processing thread is the only alternative currently.

1 Like
19

Or I’d guess one can possibly mix Rack with an ALSA backend with JACK apps without the RtAudio+JACK performance hit by using Pipewire, which includes both ALSA and JACK clients in its audio graph, or just use Rack (or Cardinal) as a plugin in a host that is a JACK client.

Edit: specifically, RtAudio/RtMidi treats other JACK clients as hardware devices rather than as virtual JACK capable applications. JUCE does this the incorrect way too. Beyond performance, it causes usability issues relating to what ports are created. PortAudio has a similar limitation with its lacking JACK implementation.

2 Likes
20

This works, but still needs some work for full v2 compatibility: GitHub - Wasted-Audio/skjack-vcv at feature/rackv2

Also need to look at a way to take over the project for v2 usage, so it can be published in the library etc. I’ll maybe spend some time on that next month.

21

I went ahead and created JACK backend treats other clients as hardware not as apps · Issue #341 · thestk/rtaudio · GitHub

Edit: in case anyone is unaware, there is not much reason to use JACK other than wanting to hook multiple apps together in one audio graph, something which happens to be incredibly handy (as in, up to a modular synth capable level of handy).

1 Like
22

I used Jack before to create my own midi-looping DAW out of jack enabled apps for some of my tracks (Similar to Non). Sequencer64+Carla+VSTs+Calf Audio Plugins + Jack Mixer. Occasionally some live input from Youtube as well. Fun times.