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.
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).
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.)
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.
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.
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.
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.
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.
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.
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).
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.