Dirt in Sound

VCV Rack
1

Hello folks,

I started recently to use the VCV rack and I dont know if its only something related to my computer but as long as I make a “complex” patch or add reverb or delay, there is a lot of dirt/noise coming up. I thought it was because I needed a sound card or smth but I tried now with a focusrite interface and headphones and it is still there…

could anyone help me? Cheers, Xavi

2

could it be that your cpu runs out of power?

have you tried to adjust the block size in Audio-8, and see the Engine menue to adjust the sampling rate and the thread count.

are you on Mac or Windows? On Win you can try different drivers direct sound/WASAPI/ASIO

3

but before that, turn on the cpu meters. are you maxing out?

4

I find having a web browser open, even with low cpu usage can cause audio artifacts

5

Maybe? when it gets noisy I always see that the reverb and the Audio-8 shows at least 25% of the power… it should not be like that right?

I tried to adjust the block size, but it gets even worst, 256 seems to be the best option but remains dirty…

I am on Windows (i7, 8gb ram), I tried with every driver and its the same…

6

Apparently I reach 25% according to the CPU Meter with the Audio8 and with reverb or delay… so I guess it gets overloaded?

7

I tried closing everything and still got audio artifacts -.-

8

Have you tried increasing the thread count, in the engine menu? I just increase by one at a time, until I find the sweet spot.

image

9

What Power Settings are you on? My machine basically doesn’t let me do music unless I switch to ultimate.

image
image731×300 7.38 KB

10

Also worth trying to reduce Frame Rate (under the View menu) to 30 or even 20 Hz

11

WOW I tried everything and this helped a lot! thank you so much! whats the technical explanation tho?

2 Likes
12

whats the technical explanation tho?

None of OS that can run VCVRack are real-time operating systems, meaning there’s no guarantee that a program is granted certain amount of execution time. Or a guaranteed maximum time responding to events.

Rack works without glitches as long as it can compute a new audio buffer in less time than it takes to play an audio buffer. If Rack uses too much CPU, or the OS, or other applications uses too much CPU. Just drawing the Rack Window also takes a significant amount of time, and the screen drawing thread competes for processing time with the audio processing thread. That’s why you can play with fewer glitches when you turn down the screen refresh rate in Rack.

Other programs running at the same time also compete for processing tome. A big culprit for glitches is a web browser – Google Chrome is really into running many threads and rendering as fast as possible.

I was getting periodic massive glitches on my new computer until I turned off the WiFi network interface. Every so often it would pretty much freeze the whole system for a second or two which is kind of shitty for playing music.

13

As of 5.0, the Linux kernel supports RTOS out of the box. You probably need to be running JACK to enable it (and there are other requirements, usually related to group membership in the audio group and the limits of that group).

Having said that, I rarely run RT, as it just seems less convenient. I run on a laptop which isn’t particularly capable, so to get quality sound I have to render it, and RT isn’t really a consideration when you’re rendering the audio (via something like JACK or a built-in VCV recorder).

14

As of 5.0, the Linux kernel supports RTOS out of the box.

I spent a couple of years working with a hard realtime OS.

In order for REAL realtime to occur there are a bunch of things that have to happen:

  1. The OS has to advertise and deliver a maximum time between an event and calling the event handler. ‘Events’ are usually hardware interrupts, but not exclusively.
  2. Event handlers have to stay in a finite time window where they lock the CPU, preventing other event handlers from running.
  3. foreground pregrams - i.e. the actual application to be delivered - also has to limit the time window where they lock exclusive CPU access.
  4. Foreground programs have a finite window to delevier data. Example for our case: the application needs to fill a buffer with audio samples before it’s needed by the audio driver.

Linux isn’t that kind of hard realtime. A ‘realtime kernel’ is some form of soft realtime.

15

Well, equating “REAL” with “hard” seems somewhat idiosyncratic, but as this is an entirely pedantic discussion at this point, the existence of RTLinux should be admitted :slight_smile: :

But it would probably be silly to make music with it. Cobbling together a working system together to make music would probably be a challenge that would not appeal to many people!

I used to run this patch set on my box:

but eventually stopped because it seemed more work that it was worth. I assume the code that went into 5.0 was a similar feature set.