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.
3 Likes
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 
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 <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
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,
}
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
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.
2 Likes
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.
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?
I don’t have time to build rack from source atm, perhaps tomorrow.
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
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:
- From command prompt, create a new empty directory somewhere, e.g. $HOME/sandbox. Change into that directory.
- Save glitchfix.sh into your sandbox directory.
- (Please review glitchfix.sh in your favorite editor and make sure you are comfortable with it.)
- Run:
bash glitchfix.shand 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 inbuildglitchfix/originalandbuildglitchfix/patched. - Change into buildglitchfix/original, then run
./Rack -d. - 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.
- In VCV Audio, select PulseAudio, choose your output device, set block size to 256 and sampling rate to 44100 or 48000.
- It is helpful to set the VCO frequency to about 80 Hz to avoid ear fatigue.
- 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.
- Exit VCV Rack. Change into the directory buildglitchfix/patched. Run
./Rack -d. - 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