How many cores is it using? My desktop is an i9 with 10 cores but runs better using 4. Maybe try knocking it down a few?
1 Like
Thanks, but there are 4 cores on both CPUs.
Well that’s weird. I tried using taskset to restrict to 1 core and it seemed to be better.
Then I tried not using taskset and it still seems to be better! A few % more use than the CPU that’s about 6 years older. But acceptable.
And still much, much better than on Windows 
Thanks for the suggestion!
1 Like
I’ve never had any success myself with multiple threads - the CPU usage seems to go through the roof. Maybe it’s the ‘older hardware’ problem.
I’ve got a thing about not buying expensive new computers
1 Like
Start reading from “Lars’ explanation of Rack performance”…
What was/is the GPU of the old and the new computer? Builtin graphics makes Rack suck…
1 Like
Hello people !
I’ve got nearly the same problem, but i don’t change the hardware, i just update my Debian, from 10 to 12. And now, it’s nealy impossible to use my old patch.
On Debian 10, i use to have 4 threads, but now, just 1 thread is possible. If i go up, the cpu consuption go over 1000%, crackles etc …
I ask to the vcv support team, and they answer that they have some problems with the multithreading on linux. It was 2 month ago, and i still don’t have news.
And, on the same computer, if i use windows 11, no problem at all … it’s really come from the new version of Debian.
So maybe you have the same issues than me, and you have to wait.
But maybe somebody have an idea how to resolve this ?
I really don’t know what to do, and for the moment, i can’t use VCV Rack on my Linux.
Since the OP is using Ubuntu, and Ubuntu is derived from Debian, it’s not unlikely that it’s the same problem. We do have some heavy Linux users in here, maybe one of them could help track the regression down. Peeps?
Another factor is, which audio driver are you using in Linux? There is JACK, PulseAudio, and ALSA. I have had the best luck with PulseAudio, although I still get frequent audio glitching unless I patch the source (see below).
I spent a couple of weeks tracking this down. I had to patch the source code for where VCV Rack initializes rtaudio’s PulseAudio layer to create a pool of 4 audio buffers instead of 2, and the problem virtually went away.
diff --git a/src/rtaudio.cpp b/src/rtaudio.cpp
index 09686a3b..a937d445 100644
--- a/src/rtaudio.cpp
+++ b/src/rtaudio.cpp
@@ -94,7 +94,7 @@ struct RtAudioDevice : audio::Device {
options = RtAudio::StreamOptions();
// options.flags |= RTAUDIO_MINIMIZE_LATENCY;
options.flags |= RTAUDIO_SCHEDULE_REALTIME;
- options.numberOfBuffers = 2;
+ options.numberOfBuffers = 4;
options.streamName = "VCV Rack";
int32_t closestSampleRate = deviceInfo.preferredSampleRate;
answer to @gael
I’m not running debian much, and I don’t know when(if) they changed CPUfreq governor and daemons.
but try on debian:
sudo cpupower frequency-info
if it’s not using the “performance” governor, use cpupower to change governor:
sudo cpupower frequency-set -g performance
I noticed something similar with the v2 release of Rack, I went from being able to use the 8 threads (most modules) as standard to having to use 1. Just trying it again now and it’s still the same for me now, testing a patch which runs ok 1 thread, if I turn up the threads up to anything > 1 then I get glitches every second or so.
Then again, if I load up a bunch of instances of Plateau to the point of the audio breaking up then performance does improve when increasing threads. So I don’t know, seems to work in situations where CPU is being stretched but harms performance when CPU isn’t being stretched.
Ok thanks everybody for your answers !
@Jens.Peter.Nielsen I install cpupower , it was on “schedutil”, i put it on “performance”, and the whole computer is clearly speeder, but in VCV it’s a bit better, but doesn’t solve the multithreading issue. But thanks for command !
@cosinekitty Do you think it is possible for me to do the same patch as you ? I mean, it is complicated to do so ? I know a bit of programmation.
@TroubledMind I try to do your experience, but it doesn’t change annything, the cpu is still over overload (some times around 1000% !!)
So thanks again for you answers, i hopes we or VCV team can fix this soon
Yes, certainly! If you are not familiar with building VCV Rack from source, it’s good to start with the official documentation. Make sure you can build and run Rack the normal way first.
Then you can use my vcvbuild.sh bash script that applies the correct patch. I just used this script this morning to build a patched version of VCV Rack 2.4.1 and I’m running it now with no more audio glitches.
Yes, thanks a lot for your answer !
I will try to do that this week-end, i will tell you what happen !
have a good day !
1 Like
Just to clarify, my fix works only with PulseAudio. It will not change anything with JACK or ALSA. So when you use it, inside your patches you should select PulseAudio in the Audio module’s dropdown box.
Has anyone actually reported this issue to VCV Rack support?
Yes I have, and I have suggested the possibility of adding a dropdown (or whatever) in the VCV Audio modules that allows changing the number of PulseAudio buffers anywhere from 2 (currently the only value supported) to 16.
EDIT: If it saves space on the screen, just a few choices like [2, 4, 8, 16] would be awesome.
1 Like
Thanks for the PulseAudio info. I will try that. I’ve always used Jack on Linux, mostly because of all the nice routing options you can get with QJackCtl
Also it’s the default setup on Ubuntu Studio. And has always worked really well for all the other audio applications.
looks like a strange thing i have 32 treads and under 8 and above 12 treads it gets worse a test patch runs on 8 by about 70% avg and 125% max
echo -n performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
RtAudio pulse: running realtime schedulin
Linux username 6.6.13-gentoo-x86_64 #1 SMP PREEMPT_DYNAMIC Fri Mar 1 10:49:26 CET 2024 x86_64 AMD Ryzen 9 5950X 16-Core Processor AuthenticAMD GNU/Linux
