Linux+JACK Rack2 performance

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

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

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.

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

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.

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

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

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

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

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

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.

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

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.

It’s not super complicated. @robert.kock “adopted” my plugins.

First of all, it’s only a special issue it your v2 plugin will be distributed in the VCV library. In that case you must have permission from the author to do that. If not, then of course you just need to follow the original license terms. Which is probably trivially easy, unless you would be violating an explicit clause about the artwork / L&F.

In my case I modified the readme to make it clear(er), and when the plugins were ported and submitted to the library I got an email from VCV (iirc) asking me to confirm that I had given permission.

2 Likes

It’s more that the code-base isn’t all that trivial and it needs some refactoring to even work properly in v2 :wink: (and I barely know what I’m doing)

It’s not super high priority for me now. My builds are functional, just that presets don’t store the port-names.

1 Like

Hi,

I had a lot of issues with 2.0.6 and my pipewire setup (which works fine with everything else I tested, using alsa, jack or pulseaudio):

  • if I select alsa, I can’t select my external USB device half of the time, and when it works it gives distorted sound (might be a resampling issue in my system, though)
  • if I select pulseaudio, it says no device available
  • with jack, I have duplicates in the interface list (gets worse if I unplug / replug the device, or restart pipewire). But if I select the right one, I did have sound output, but very bad quality (even changing monitor output volume on the interface wouldn’t be linear, and crack and pop often)

It does get better with 2.1.0, thankfully :slight_smile:

  • with alsa, I can select my card. Still distorted though. Doesn’t matter, I want to use Jack.
  • with Jack, no change: still duplicates of my interface, and bad sound.
  • with pulseaudio, I can see my interface now. And it works fine ! No sound distorsion or probleme with output volume, and I can plug everything I need using qjackctl (thanks to pipewire implementing a jack server).

It’s not super high priority for me now. My builds are functional, just that presets don’t store the port-names.

Out of curiosity, I tried to build your fork from the branch. It does work fine except for the port names, which would be useful. From the code, a few experiments (I’m not a C++ person) and the Rack API doc, the problem seems to be that overriding ModuleWidget::toJson and fromJson can’t work in v2. If using dataToJson and dataFromJson isn’t an option (didn’t go that far), that means this would need to be done by overwriting Module::toJson instead but here I’m far beyond my C++ skills. (Pointers taken from Alternative to overriding Module::fromJson? - #5 by computerscare and To/From JSON Question - #4 by unlessgames)

Anyway, thanks for your work on this @dreamer, and while it’s usable, it’d be great if you (or someone else) find the time and motivation to tackle the porting of Skrylar module, as I don’t think I’ll be able to be useful here :wink:

1 Like

Based off your work and nielszweistein’s I also now have a functioning version without port naming and given it meets my usecases far better then the VCV module I might try and spend some time getting the rest working GitHub - simotek/skjack-vcv2: First-class JACK support for VCV Rack was my WIP you can build this and use it without port naming. I’ll update the thread if I actually get something polished.

2 Likes

in my personal experience I have installing pipewire and setting two times in two new ubuntu installation in two different computers, and it work very bad for both , I got many issues as you plus freezes of the rack , I want to not recommend the use of pipewire in the linux FAQ , pipewire maybe is cool for a youtuber but feels like not work property for musicians , try to keep out pipewire for your audio equation

Hi, yes this is my experience also. I use fedora 36-38 and in normal usecases pipewire is great. But for heavy audio usage i always get errors,stuttering and high cpu load. Create an issue on github pipewire brings nothing. Therefore i switch to avlinux and there it works like a charm.

1 Like

I now have a port that’s usable and worth sharing. https://community.vcvrack.com/t/stkjack-linux-jack-plugin-rebuild-of-skjack-vcv/

1 Like