VCV Rack engine terminology

VCV Rack
1

I want to keep this conversation narrow at first to better understand, then ask specific questions if merited. I realize, when VCV Rack v2 arrives, all of this may become moot. If that is the case, that’s the case, however in the mean time, we are still on VCV Rack v1.1.6.

What does real-time priority do? Should I always have it on, or should I leave it off? I have found specific topics regarding Linux but none for Window users, nor macOS. Should this always be off on a windows machine? I am running Windows 10 (x64)

VCV Rack engine sampling rate: [this is different than the audio sampling rate] Is that a correct statement? Should this always match the audio sampling rate, or is it proper to have it running faster, if possible? I was trying to run this faster and that’s when the wheels started to come off. I could audibly here a difference when it was faster - when it worked and it did under the right scenarios. Obviously, when things got whacked, I just reduced the rate to my original setting. Should this even be touched?

I am just needing clarification since I could not find enough in the documentation nor on the community boards, exactly how these parameters work or their true meaning.

2

Hi @gtilde!

Sampling rate: Setting the engine rate higher than the audio rate basically does oversampling at the engine level. This is, to generalize, going to reduce artifacts for certain kinds of audio processes. Unless you’re going for a specific digital sound, I’d generally keep it as high as you can without causing, as you put it, the wheels to come off, especially if you’re doing things like audio-rate modulation, feedback patching, or saturation. Since it’s engine-level, not all modules are going to take maximum advantage of it, but it can make the sound different in ways that are technically “better” and which might sound better to you as well (cue “if it sounds good, it is good…”) In any case, it’s an interesting parameter to play with. Experimentation definitely encouraged.

Real-time priority: Other than @Vortico (obviously), @Squinky is the resident expert on real-time priority, as the Thread Booster was the 0.6.x precursor to this feature. It tries to reduce or eliminate audio dropouts by making it harder for other processes (where delays may not matter so much) to cut in front of the audio engine. Here’s some documentation. I think the basic idea is to keep it on unless it seems to be causing problems (or if you have something going on in another program that’s more important to you than glitchless audio playback). I always keep it on.

3

Yes, I recommend boosting the audio thread priority. The basic idea is that producing audio is the most important thing when you are running VCV. If you touch your web browser, for example, you most likely would prefer that VCV continue to play, even if it means the browser has to wait a few milliseconds before it redraws the screen. You don’t want some random app updater to wake up and block your audio either, mostly likely

More in the VCV world, many VCV plugins make their own threads for background processing. In most cases you would prefer that the audio continue smoothly, and you can usually assume any VCV plugin that spins up its own worker threads will tolerate those threads being a tiny bit late.

AFAIK most audio software runs their realtime audio rendering code at the highest possible priority.

1 Like
4

FYI looks like VCV v1 not implemented thread boosting for macOS.

5

That would be unfortunate. I’ll have to look in there and see.

6
7

I looked at your git diff. Very impressive. In my old thread booster plugin I used used the same pthread code on linux and mac. I’m sure your mac specific version gets the priority even higher. excellent.

8

@gc3 and @Squinky thank you for taking on my questions. There is more to come, but totally understanding how these work will help me discover the rest of my troubled story.

@gc3, when I was able to run vcvengine at a faster sampling rate, (my audio device is set at 48khz/24bit), I was able to run the vcvengine at 88.2kHz, a couple times even at 96kHz, but generally at 88.2 I had the most success - but, this depends. I could indeed hear a positive difference, yes it sounded better so indeed it was much better. The audible difference was enough for me to think I want this all the time. Why can I not have this all the time? (a plethora of reasons) This is why this topic is very important, and ostensibly might help others.

@Squinky, so my suspicion was correct. From my previous knowledge the term means as it says, give VCV Rack real-time thread priority. That is what I expected it to mean, but I was not clear on how VCV Rack viewed it. TBH, when creating, I always keep the WiFi off, along with a grand-list of tasks off, so to cause the least conflict for CPU cycles as possible. Running Windows 10 for music creation efficiently, requires a lot of internal tweaking. Which brings me to a more specific application of the question and why the clarification of the terms meaning was important.

How well does it “compete” when other music applications are running? Depends on the other app I suppose - but does VCV Rack want to always win with this is on? Does it share the priority with others well if it is on (w/Reaper, Ableton)? How well does it play with others if I am using vcvBridge? When I have VCV Rack running on a dedicated gpu, forced, by setting it in the graphic settings in windows, will this also come into play if another app is occupying that GPU if it is running too?

I totally understand that a lot of things are at play here. I also understand, I, as a user, need to totally understand the variants of the parameters, what they mean and how this will effect everything that I am doing. I have had some problems, big problems, we may get into, but I want to understand how these things really work, first.

1 Like
9

Running multiple audio applications is always tricky. There will always be some amount of uncontrollable fighting. If I’m correct that most other audio apps use realtime, then you don’t want those apps winning all the time, so boost VCV to give it a chance.

Btw, the thing with 96k sounding better… It’s only dramatic for poorly designed plugins. It shouldn’t sound much different for properly designed plugins. From time to time you may hear me complaining about aliasing in other plugins. It sounds bad. And many plugins without alias mitigation sound bad, and running them at 96k does provide some mitigation, so…

fwiw, “good” plugins user oversampling internally, or simulate it with minBLEP math to give an effective rate much higher than 96. I’ve seen plugins commonly use 4X,8X,16X oversampling… 4X is 192k and it goes up from there.

If you go rooting around here you can get more of my opinionated opinions on this (and some objective info): Demo/aliasing2.md at main · squinkylabs/Demo · GitHub

1 Like
10

caveat : many plugins don’t need or don’t benefit from alias reduction. Typically many VCOs need it, and almost all waveshapers. Filters are a whole other topic…

11

Since many “good” modules already offer oversampling internally at a very high rate, from what you have offered, I can conclude, increasing the vcvengine isn’t buying me anything except heavier CPU usage that will cause audio anomalies, buffer over-runs, glitchy-mania lets just not do this ever again, scenarios. From what I am understanding, setting the vcvengine at a higher sampling rate provides manual oversampling but affords little to nothing for better performance or better spectral ‘high-fidelity’ sound in the end, except providing help for the “not behaving” modules who need the corrections manually (now, how are we, as users, going to know which ones need this help ? ? ).

Is this a proper conclusion for the vcvengine? I currently have vcvengine set at 48kHz, which matches my audio device sampling rate. I see no reason, to change it . . .

As for the audio thread priority, I will keep it enabled so it can compete with other cpu threads that are running realtime audio.Thanks for the clarification. True, running multiple audio applications is always messy and yes very tricky. There is so many things at play.

@Squinky, thank you for the links and extra reading. I have already started digging into it a bit, your work is much appreciated . . . more to come.

2 Likes
12

I think that statement might be true for oscillators and waveshapers/saturators under no (or low-frequency) modulation, where we’re focused on reducing aliasing. Extending that principle, if you’re using high-end (meaning carefully programmed) oscillators in a standard subtractive synth workflow (VCO->VCF->VCA, LFOs, simple envelopes, little distortion) it’s unlikely to be that useful.

However, engine oversampling can also change the effects of higher-frequency modulation as well as feedback, and in a way that modules can’t really compensate for, so I wouldn’t necessarily stop experimenting with it, especially on more intricate patches.

Curious to hear about others’ experience with (and use of) engine oversampling. I often get a patch to about where I want it with engine rate equaling output rate (so that I don’t feel overly restricted in terms of adding modules) and then try bumping the rate up to see if it (1) doesn’t glitch and (2) sounds better to me. If it doesn’t sound better, I keep it at the lower level. If it glitches but sounds better, I consider whether it’s worth trimming the patch down. If it doesn’t glitch and sounds better, great!

13

oh, I totally agree with that. Try it and see. I can certainly tell you that I don’t worry nearly as much about aliasing and such through CV inputs (unless they are obviously “audio rate”). So, sure, try it and see.

14

Same here

15

And, for anyone who doesn’t know already, @LarsBjerregaard is very picky about his audio quality!

16

so we shall revisit this topic again…

yes, I brought this thread into the conversation, with a direct question to you both @Squinky @LarsBjerregaard Oh, and @gc3, please take a view too!!

I have been trained in my academic endeavors and day to day work, that critical listening is important. I am very picky to audio quality as well. It is good to hear @LarsBjerregaard is equally paying attention.

1 Like
17

Just an aside to say that audio quality is about a lot more than samplerate. I would venture to say that at least the following factors are at play, in descending order of importance, as to the audio quality anyone perceives as it is hitting their ears:

  • Quality of your headphones, or
  • Quality of your monitors and room treatment(!).
  • How well you actually perceive sound/your listening ability/training.
  • Patching skills(!) You can ruin the sound of almost any module :slight_smile:
  • Quality of/ability to mix and master a recording.
  • Quality of DAC/audio interface, cables, etc. etc.
  • Samplerate, bit-depth.
  • …
4 Likes
18

yes indeed, a lot at play as experiences have shown us. I will counter, if your sampling rate, say recording an acoustic signal is low . . the litany of items you suggested, will not fix it. If the information is not there, it is not there. . .

19

@gtilde no need to counter, just add it to the list

and we can add some more points like the personal taste of the listener and the listening habits which may also influence the perception of sound

20

@rsmus7 I respectfully disagree… you missed the context