Clicks/pops using VCV Rack 2.1.0+ (EDIT: was "2.2.0")

I just installed the new VCV Rack 2.2.0 on two of my Linux boxes. I also kept 2.0.6 in a separate directory. I’m consistently getting random clicks and pops with the new version. It happens on both systems I have tried it on. The distortion happens even with very simple patches, so I know I’m not overloading the CPU. For example:

I tried recording the glitches to a WAV file, but they don’t appear in the recording when I play it back. So it must be something wrong with sustaining real-time audio rendering.

I keep switching back and forth between 2.0.6 and 2.2.0. It never happens in 2.0.6 but it is easy to repeat in 2.2.0. I have gone back and forth about 6 times and the difference is 100% consistent.

It happens most often when switching windows (e.g. pressing Alt+Tab), opening new browser tabs, etc. But even when I close all my browsers and other applications, it happens every now and then.

But 2.0.6 doesn’t do this. I can’t get it to click/pop no matter what I do.

In the Audio module, I’m using PulseAudio at 48 kHz, block size 256. Same thing happens with 44.1 kHz and/or block size 1024.

Is anyone else running into this? Any ideas on what I can try?

I haven’t tested yet. It would probably be better if you did the comparisons between v2.1.2 and v2.2.0. Just from looking at the code changes, might it have to do with this, or this or this change?

RtAudio has been updated after 2.0.6 too.

Update rtaudio submodule. This fixes audio devices with Unicode names… · VCVRack/Rack@94de041 · GitHub

Probably totally unrelated … on windows, my audio crackles, if i forget to select a “high performance” power plan and do not run rack in the foreground.

I think the rack default thread priority changed somewhere around 2.0.6.

Might want to try running rack to jack instead of pulseaudio ?

I have similar, audio is distorted / clicky, was the same with 2.1.2 so I’ve been on 2.0.6 since its release. If I up the block size things do improve but still reluctant to use, some post 2.0.6 change has caused this and it remains in 2.2.0.

Ok, maybe the OP never ran v2.1.2 either and this is actually about audio crackles introduced, for some people, after v2.0.6, and has nothing to do with new problems in v2.2.0.

Have you guys made support tickets about this?

I have.

Module browser is also now so slow compared to 2.0.6 it’s almost unusable. Gone back to 2.0.6, again.

I was having problems with the browser not being able to cache all of the module images except extremely slowly with hangs. I had a complex patch that was using lots of CPU. I switched to a minimal patch and the browser was able to cache all module images. I then returned to the complex patch and things seem okay.

Thanks for the ideas and suggestions, everyone!

Yes, that is correct: I jumped directly from 2.0.6 to 2.2.0. I will spend some time today testing the intermediate versions to figure out where the glitches start on my system.

If I can get the VCV Rack source code to build without too much hassle, I will do a git bisect to isolate the root cause.

This sounds like a likely cause of the glitches. In fact, one interesting observation is that, in 2.0.6 and 2.2.0, I see the following if I run Rack from a terminal window:

$ ./Rack

MidiInJack::initialize: JACK server not running?

MidiOutJack::initialize: JACK server not running?

RtAudio pulse: _NOT_ running realtime scheduling
RtAudio pulse: _NOT_ running realtime scheduling

So another thing I will do is research whether I can turn on “realtime scheduling” and solve the problem while using 2.2.0.

When I try to select JACK in the VCV Audio module, I don’t see any devices. I really need to learn more about audio on Linux. I only have a vague understanding of ALSA, PulseAudio, JACK, etc. But if I understand correctly, JACK was intended for audio production work where glitches are unacceptable (a sentiment I share). So maybe if I spend a week or two doing the Linux thing where I bang my head against the wall and curse enough, I can get it working, LOL.

I’ll report back here once I learn anything interesting.

1 Like

First discovery: I can easily reproduce the glitching in 2.1.0. I tried again to make 2.0.6 glitch and I still can’t. So that narrows the search. Based on other threads here today, there are some issues introduced in 2.2.0, but this isn’t one of them. If your audio was glitch-free in 2.1.0+, you can likely disregard this thread.


Hmm, that doesn’t sound good, will have to test.

Understandable, but I don’t think it’s a sustainable strategy in the long run, because the API is changing, and new modules might become unrunnable/flaky for you because of it.

It does and it needs more testing, good repro cases and support tickets I’m afraid. I’d be interested to hear if Andrew has rejected this because he can’t reproduce it.

I think it’s always said that on Linux actually, whether someone is using the Jack driver or not, and it can be misleading of course. I would probably disregard it as a test that Rack always runs on Linux, no matter how relevant it is.

Sort of like above. I suspect that it’s misleading, and can be read as “you’re doing something wrong” where in actual fact it’s just informational, and downright irrelevant if you’re not using the Jack driver.

It’s not… uncomplicated :slight_smile: My impression of Jack, also having tried it is this: For many it can be a right pain in the neck to get running and configured properly, but for those who manage they swear it’s the greates thing ever, and I tend to believe them. Lots of patience required…

Yeah, I suspected that. So you’re in the unfortunate, smallish group of people who experienced a serious regression in audio after 2.0.6, and I feel for you. I think they’re all on Linux but not 100% sure.

Yes, I think so, and I believe there’s already some topics on the forum on the post-2.0.6-audio glitches issue. I’m surprised it hasn’t been diagnosed and solved yet, but do remember that (unfortunately) the Linux users are by far the smallest userbase of Rack.

1 Like

I installed the new version 2.2.0. The module browser is as snappy as always, on this 8 year old iMac. Works great.

I have isolated the commit that introduces glitches on my Linux system: it is an update to the version of RtAudio. [Edit: fixed commit link.]

When I build and run the preceeding commit, the audio is flawless:

commit 05d93da0baa913d1db05f99f670e9f910139327c (HEAD)
Author: Andrew Belt <>
Date:   Mon Jan 17 18:32:26 2022 -0500

    Switch to VCV's rtmidi branch. Update rtmidi from upstream.

But this commit introduces clicks and pops:

commit ac73ef478a0ef87dc1f7360bf2c735459ba41943 (HEAD)
Author: Andrew Belt <>
Date:   Thu Jan 20 05:35:01 2022 -0500

    Update RtAudio to 5.2.0. Rewrite error handling in RtAudioDevice.

Most of the changes aren’t in VCV Rack proper, but in the dependency submodule RtAudio, which was upgraded from version 5.1.0, commit 8128053f4bd83463c7c901d9f5d40b272c2f4e4e, to 6.0.0beta1, commit e5cfcd557a480cc1a6a1ef1204474221798abb60 (not 5.2.0 like the commit comment says).

However, there is enough breaking change in RtAudio that I can’t just roll back to 5.1.0 without causing the VCV Rack build to break.

But at least I have hope now that this can be tracked down and fixed for good. More research is in progress. I will report back later with an update.


Excellent and well done!

Great news! I have figured out how to fix the audio glitch on VCV Rack 2.1.0+. Please note that this glitch, and the fix for it, affect only Linux users who select a PulseAudio output device.

If anyone else has experienced clicks/pops using PulseAudio, and you know how to build VCV Rack from source, it would be great to confirm that this solves the problem.

The issue is in the VCV Rack fork of rtaudio. The following patch makes the glitch disappear on my system:

diff --git a/RtAudio.cpp b/RtAudio.cpp
index e59a8ed..8d39e46 100644
--- a/RtAudio.cpp
+++ b/RtAudio.cpp
@@ -9264,20 +9264,7 @@ bool RtApiPulse::probeDeviceOpen( unsigned int device, StreamMode mode,
   case OUTPUT: {
-    pa_buffer_attr * attr_ptr;
-    if ( options && options->numberOfBuffers > 0 ) {
-      // pa_buffer_attr::fragsize is recording-only.
-      // Hopefully PortAudio won't access uninitialized fields.
-      buffer_attr.maxlength = bufferBytes * options->numberOfBuffers;
-      buffer_attr.minreq = -1;
-      buffer_attr.prebuf = -1;
-      buffer_attr.tlength = -1;
-      attr_ptr = &buffer_attr;
-    } else {
-      attr_ptr = nullptr;
-    }
+    pa_buffer_attr * attr_ptr = nullptr;
     pah->s_play = pa_simple_new( NULL, streamName.c_str(), PA_STREAM_PLAYBACK,
                                  dev_output, "Playback", &ss, NULL, attr_ptr, &error );
     if ( !pah->s_play ) {

If your Linux/PulseAudio has random clicks/pops, especially when switching windows, can you please try applying this patch and let us know whether it solves the problem for you too?


[EDIT] For clarification, this file is in one of the git submodules, under the directory dep/rtaudio. So you need to apply the patch after executing

git submodule update --init --recursive

and before executing

make dep

I went ahead and forked rtaudio and applied my fix to it.


That’s great, well done! You should definately try and make Andrew aware of this. Thanks for the effort Don.

1 Like

Yes, I will contact him soon. First I want to do more testing on multiple systems to make sure this is a solid fix. I’m looking for volunteers to help. Basically anyone who has VCV Rack running on a Linux system with PulseAudio installed. Please reply here if you can help.


I use PulseAudio JACK sink, happy to help.

1 Like

Great! To be a good test, I want to make sure it also glitches on your system. That way we can demonstrate the fix is really a fix. I will come back and provide more instructions later if that helps. Just let me know.

1 Like

In 2.0.6 I had a block size of 256, on 2.2.0 I had to up that to 1024 to get clean audio.