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

VCV Rack
12

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 <andrewpbelt@gmail.com>
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 <andrewpbelt@gmail.com>
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.

7 Likes
13

Excellent and well done!

14

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,
     }
     break;
   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?

Thanks!

[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
make
2 Likes
15

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

3 Likes
16

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

1 Like
17

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.

2 Likes
18

I use PulseAudio JACK sink, happy to help.

1 Like
19

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
20

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.

21

Yes, I also found increasing the block size helps, although it doesn’t completely fix the problem. So in your testing, can you put the block size down to 256 and set the sample rate to 48000 or above?

22

I don’t have time to build rack from source atm, perhaps tomorrow.

23

That’s fine. I plan on making a bash script later today that will automate building with and without the fix, for a proper A/B test. So when you do get around to it, the script should make it go a lot faster.

1 Like
24

Here is a pair of scripts to help build Rack with and without my fix, into two separate directories, for A/B testing.

How to use them:

  1. From command prompt, create a new empty directory somewhere, e.g. $HOME/sandbox. Change into that directory.
  2. Save glitchfix.sh into your sandbox directory.
  3. (Please review glitchfix.sh in your favorite editor and make sure you are comfortable with it.)
  4. Run: bash glitchfix.sh and give it about half an hour to finish. It will clone and build Rack from source twice, one without my fix, one with my fix. The resulting builds end up in buildglitchfix/original and buildglitchfix/patched.
  5. Change into buildglitchfix/original, then run ./Rack -d.
  6. Clear out the template patch and add just two modules: VCV Audio and VCV VCO. Patch the VCO sine output to the VCV Audio left input.
  7. In VCV Audio, select PulseAudio, choose your output device, set block size to 256 and sampling rate to 44100 or 48000.
  8. It is helpful to set the VCO frequency to about 80 Hz to avoid ear fatigue.
  9. To reproduce the glitch, start switching between windows, open your browser and switch between browser tabs, etc. You should easily hear clicking and popping. I find YouTube especially makes it happen, even though no video is playing.
  10. Exit VCV Rack. Change into the directory buildglitchfix/patched. Run ./Rack -d.
  11. Repeat steps 6…9. Only this time you should not hear any glitching no matter what you do. (I hope.)

The other script, glitchinst.sh, will create “installs” of Rack, but I’m still having problems running Rack without using the -d option. So that script is just for reference for the time being.

I’m hoping I can get some independent confirmation that my fix solves the PulseAudio glitching before I contact Andrew.

Thanks in advance! Any help here will help lots of VCV Rackers running Linux.

2 Likes
25

As an update on this issue with clicks/pops in VCV Rack, I learned something new today. It turns out that my suggested fix mentioned above causes about a half second of latency in the audio rendering. If you are building Rack from source, instead of patching rtaudio, try changing this line from this:

    options.numberOfBuffers = 2;

to this:

    options.numberOfBuffers = 4;

After doing that on my system (Debian Linux + PulseAudio) all the glitches are gone, plus the latency is imperceptible.

More details are available in my pull request in rtaudio.

1 Like
26

So it sounds like perhaps VCV should change this or offer an option. I think that’s what your are suggesting?

27

Yes, exactly. Building Rack from source for myself, I am content to just change 2 to 4. But I imagine the VCV Rack team would feel a lot safer keeping the default to 2 but allowing an optional setting where users like me can change it to whatever we want.

28

just hearing "change 2 to 4 makes my think it would double or triple the latency. Of course I don’t really know.

29

Yes it will. But the default block size is really small, only 256 (bytes? samples? not sure…):

[0.315 info src/rtaudio.cpp:118 openStream] Opening RtAudio PulseAudio device 1: Built-in Audio Analog Stereo (0 in, 2 out, 48000 sample rate, 256 block size)

So this will be a tiny fraction of a second, which is way better than my first attempt at a fix, where the latency is really noticeable (like half a second or something like that).

30

yeah, but the block size is settable by the user. at least if they are running an ASIO interface there is an ASIO control panel that let’s you set it. And 256 isn’t really small - its a pretty reasonable default. So, yeah, a few tens of milliseconds is better than half a second, but could you get the same effect by increasing the buffer size, when users presumably have control over? image

31

Yeah, that’s the thing. Increasing the block size was the first thing I tried back in November, but the glitches still happen no matter how large I make it. (I just confirmed again on my system to make sure I wasn’t going crazy.) It only happens in Rack 2.1.0+, but not 2.0.6. I traced this to a change in rtaudio, which led me to the number of blocks being the key variable, not the block size.

2 Likes