VCV Recorder crackle/cpu spike

For some unexplained reason the VCV Recorder is causing serious audio crackle while recording video. This is something new - I’ve made dozens/hundreds of videos of my patches, but in the last week or so, something has changed. I’ve simplified my patch down to about the barest bones 3-module patch you can imagine - a VCO feeding both Audio to my headphones and to the VCV Recorder. As long as the recorder is not recording, it sounds fine. As soon as I press the red Record button, audio starts crackling badly (and I think I hear feedback through the crackles?). Shortly after I turn off the recorder, audio returns to normal.

I’m working with support, but so far we haven’t been able to pinpoint what’s wrong. Has anyone else experienced anything like this. Any suggestions of things to try?

  • VCV Rack Free 2.3.0 x64 (running on a M2 MAX under Rosetta2)
  • Macos Ventura 13.2.1
  • Rack settings: 1 thread, 44.1kHz sample rate, 10Hz frame rate
  • Recorder settings: format: mpg (MPEG-2), 44.1kHz sample rate, 128 kbps
  • Audio settings: Core Audio, External Headphones, 44.1kHz, 256 block size

FWIW, I just tried installing older versions of Rack to sanity check that this was not something caused by the 2.3.0 upgrade. Both 2.2.2 and 2.2.3 have the same problem on this laptop.

All evidence points to some configuration problem on my machine. But I am at wits end trying to find it.

A possible explanation. Recorder chokes when I try to record a very large window (about 3000x1700 pixels – about 80% of my 4K monitor). If I shrink the window down to 1300x900, Recorder seems much happier. So this might be a simple “too many pixels to record in real time” problem?

(while my Rack and hardware config hasn’t changed, I did recently change my external monitor for a gargantuan 4K monster and started running Rack in much larger windows. So this may be the root cause of the problem. I’ll check in with VCV support to see if they’ve done any testing on large windows.

GFX engine of VCV in hungry

Vector GFXs are hungry

1 Like

GPU accelerated vector processing could be the next step

I keep my default block size at 1024, which has fixed a noise problem I was having even without recording.

When you play them back, do the recordings have the noise as well?

[edit - MacBook Pro (13-inch, 2019, 2.4 GHz Quad-Core Intel Core i5), Monterey v12.6.5]

2 Likes

One other thing: When I use the REC module to record video and audio, I get dropouts in the audio after about 10 seconds when I play them back in QuickTime Player. Often, when I rewind a few seconds, the audio is okay for a while. They’re much better in the VLC media player.

I get better (?) results if I use the QuickTime Player to do the screen recording, but to get the audio at the same time I have to jump through hoops with the Soundflower extension as an audio input for the QT Player recording. If I want to hear it while it’s recording I have to have two AUDIO modules - one for Soundflower and the recording, the other for me to hear it through headphones.

1 Like

I can’t even play the stuff from recorder on windows - at least not without thinking. I use some other program to transcode it to mp4.

2 Likes

Try switching to 2 threads when recording. Works for me.

1 Like

Blackhole, soundflower hasn’t been updated in ages. Super easy, make a multi output in AudioMIDI app, and use that in Rack, then have Quicktime pick up audio from the Blackhole(2-16-64 channel), whichever you added to the multi out device. Needs doing only once and Quicktime remembers that as default. Never an issue here.

3 Likes

Same for me on mac. I transcode the MPG to MP4 with ffmpeg in order to play/share the video.

2 Likes

I also use VLC media player to convert the files to MP4 before even viewing them. With the right settings it can compress the file size to about 10% without any noticeable degradation in audio/video. It is also much easier to upload a 20mb file than a 200mb file. And it can play fine in any player.

FWIW, increasing buffer size and trying 2 threads instead of 1 makes no difference on my machine.

On my older mac, with smaller windows, if Recorder crackled during recording, the resulting video was often (usually) crackle-free - and this usually only happened if I was pushing the boundaries of number of modules/complexity of the patch for my woefully underpowered machine.

On the new machine, with the 4K oversized window, the resulting video is just as crackly as the realtime monitor no matter how simple the patch.

Recording with Quicktime/blackhole works fine. And a simple workaround of temporarily reducing the size of the window during a recording seems reliable. So I have a way forward.

I wonder if a native ARM Rack will behave any better. This machine has a monster GPU - ffmpeg transcodes almost instantaneously where it might have taken 5 minutes on the old laptop. But I’m not sure how much effort is going into supporting the new mac hardware…

Can confirm it has a lot to do with

A) module count

B) window size

I have a 5k iMac and the only way I can use VCV Recorder is if I shrink the window to a quarter of the screen. That’s why like mentioned above, I switched to either recording in QuickTime or Streamlabs/OBS.

Recording with Blackhole and Quicktime is the way. The issue is - if you record the screen with Recorder, it happens on the audio thread, which now competes for the same CPU core as your music. On top of that, if you’re recording to a compressed format, like MP4 it uses a lot of resources for the compression, still on the audio thread. It’s no good. Instead, when recording via an external screenrecorder, like Quicktime, you’re offloading that recording to other CPU cores than your music, plus the compression/transcoding only happens when you press Save in the end. It’s a much better way of doing it.

For those on Windows you can use the “Xbox gaming bar” in Windows plus a virtual audio router (banana-something?) - works in the same ways as Quicktime+Blackhole/Soundflower.

Oops, the reply was supposed to be to @Chinenual , sorry.

3 Likes

I decided to give that a try, but it was not easy to find a free version to download.

Super easy, make a multi output in AudioMIDI app, and use that in Rack, then have Quicktime pick up audio from the Blackhole(2-16-64 channel), whichever you added to the multi out device. Needs doing only once and Quicktime remembers that as default. Never an issue here.

:open_mouth: I never knew about setting up a “Multi-Output Device” with Audio Midi Setup before. Now I’ve got a “BlackHole+Headphones” device. By golly it works, so my earlier remark about using two AUDIO modules to listen during a screen capture can be ignored.

However, it may be still useful to have two AUDIO modules in order to monitor audio upstream of any fade-in/fade-out module during a recording.

Yeah, aggregate audio devices, including with virtual audio routers/interfaces, works extremely well in macOS, and takes a lot of pain out of audio, together with no drivers needed for class compliant hardware. It’s one more of the reasons why musicians and creators in general prefer macOS. It’s really not a fashion statement but a very practical “It just works” or “much less pain” consideration.

1 Like

I was getting a terrible crackle. For me, it ended up being my Bluetooth headphones.