I downloaded a couple of patches lately, one from State Azure - Silk Nebulae (Silk Nebulae - Ambient Modular (VCV Rack) - YouTube) and another from cvly (cvly modules updated for Rack 2 - YouTube). I assumed that perhaps the Silk Nebulae one was created in VCV 1 so that’s why I had a problem but the cvly patch was created quite recently and the modules are now in the library - with either of these I get a terrible distortion using ASIO. I get better results using Direct Sound but still not as good as it normally sounds. My interface is an 18i20 3rd gen.
Any thoughts? I was going to load one of them to Patchstorage but since they’re not mine I probably shouldn’t. Any way to share it here should anyone want to investigate?
It is pretty unlikely that DirectSound would outperform ASIO. And Focusrite stuff is generally a pretty decent budgetfriendly choice. So I assume your audi interface (and driver) is not the cause.
More likely, and therefore assuming: buffer underrun (“audio stutter”).
Some things to check and try (to find the cause).
What’s the CPU usage (upper right corner in VCV Rack? If it regularly exceeds 100%, you might run into trouble here and there?
Try and press F3, to get performance info per module. This process requires extra computing power for itself to work, so pressing F3 might temporarily make things worse, which in itself will tell you there’s a lack of processing power.
How many threads are you allowing? 1, 2, 3 or 4 (or even more) threads? More threads can spread the CPU load (but more is not always better).
What samplerate are you running at? 44.1Khz, 48Khz, 96Khz, 192Khz or other?
What buffersize is set. 64, 128, 256, 512, 1024 or other bytes? Smaller buffers, requires more computing power.
What (GUI) framerate are you running. Higher rates, requires more computing power.
About energy saving options. These might restrict the ‘top’ speed of the processor, thus saving energy. But also, possibly causing too little processing power to keep up with extended periods of high loads of realtime (audio) applications, and thus cause glitches (buffer underrun).
Are you running VCV Rack on a laptop? And is it (sometimes) NOT plugged in wile running VCV Rack? Then it might soon activate these ‘energy saving’ options and cause glitches.
Also…network traffic may cause (unnecessary?) load. Might be scanning network resource/device statusses, refreshing webpages or advertising, checking email or download updates and stuff. Disable WiFi and/or network adapter when running VCV Rack undisturbed…
By default, the Engine Sample rate is set to “Auto” (yellow arrow) and will change this value based on your Audio Device’s sampling rate.
Which, in my opinion, keeping it Auto is wrong, from the understanding I have with how the “Engine Sample Rate” which is tied how a module will run - its computations. I am certain I am simplifying it, but my ears and the performance do not lie. I had a conversation, with @Squinky and @LarsBjerregaard about a year ago, asking rhetorical questions, to bring to the surface the real meaning of these settings because it impacts the performance and audio drastically. These conversations were to shed light and get to the true meaning of these settings - and how it is used in Rack.
I have been meaning to ask them both - “okay, then why in Rack 2.x is this set to Auto as the default” if it is tied to the oversampling rate of how a module will run? Which, as I learned from the conversation was to help “bad module” performances perform better. Auto, implies there is a direct correlation between the Audio Interface sampling rate and Rack’s Engine sampling rate
I still have not heard or seen an answer, how a non-developer user, who is using Rack for creating music, KNOW, if that module is a bad performer and oversampling is needed - unless you are a coder. How of the 20 modules you have in the patch, need some extra juice?
Not all modules are created equal…nor systems…some modules it does nothing, others it affects drastically.
From my understanding of earlier conversations, these two settings are exclusive.
It appears it is the same for Rack v2 Pro - in part ???
These settings, for example if your audio interface device sampling rate is set at 96khz, it AUTO Switches the Rack Engine Sampling rate now is set to 96kHz.(see screenshots) This honestly causes things to sound awful, run badly, and so forth.
I have the experience running v1.16 patches and placing it in Rack v2 - yikes.
I now default my Rack Pro 2.06 to Engine sampling rate to 48kHz (see red arrow). I can change my audio interface to 96khz now and all sounds great.
There are a plethora of things to look at, but I know these settings are worth a spot - check, and honestly, further investigation.
I used to post data on modules I thought were bad performers. I can tell you it didn’t win me any friends! I think the general reputation is currently “VCV doesn’t sound as good at the others, but there’s lots of variety and it’s free”. That’s unfortunate, and not true, but so be it.
Say what, VCV sounds worse than the others? Not here it doesn’t. Maybe I am jaded, but sound quality has never been an issue for me. I could moan about a few other things but that would do no good…
Auto is the right choice for almost everyone, because it means that the engine will run at the same samplerate as the audio module, which means no re-sampling is needed which is very good for your CPU.
Hmm, kinder to the CPU … so there IS a direct correlation with the engine sampling rate ? ? I am not sure I have read this anywhere, except, 15m ago
I do not wish to get off topic of the OP questions and concerns (apologies @fpssdave). . . but, I am not clear on your point. I most certainly have not seen, or appreciated the audio results from this behavior - perhaps I’ll should share my results on the other thread for further discussion.
No, speaking directly to the uses of this within the Rack application and how well it runs and modules sounds
I was meaning, the Rack Engine Sample rate and setting your Audio device’s sampling rate. I am not speaking to CPU usage. Both changes how the cpu performs along with plethora of other items. I am speaking directly to how Rack uses this information.
The clipped comment before…was questioning your comment
You would think calling attention to room for improvement would be welcomed. It’s one one the advantages/goals of open source. But alas it is often perceived as some sort of attack or threat.
It’s pretty obvious that, since machine resources are limited, efficiency counts.
Especially when working with realtime applications. And…due to the inherent flexibiity and the subsequent many permutations of any modular system, it is pretty hard to optimize for some specific permutation(s).
So we should allways strive to optimize all links (modules) in the (potential) chain(s) to be able to take full advantage of all combined functionality (before everything prematurely comes to a stuttering halt).
“As good as”…is highly subjective and contextual to begin with…but…
Yup…the common misperception is that price is always related to actual value. This is great news for many manufactures/sales guys that can then sell stuff for way to high prices to actually make buyers happier with their (too expensive) purchase.
And yes, just like the VST plugin eco-system, there are differences in price (money) and value (quality). Not correlated per se.
Anyway…
Yes, sometimes there are functional or performance issues with some of the payed and/or the many, many free options…but on the plus side, there are so many creative and quality modules to choose from. With a low threshold to enter usage and/or development.
And yes, it is generally a good idea to keep a keen eye on functionality AND performance of individual modules.
kwurqx - Yes the Focusrite has had a few issues but generally it sounds quite good.
What’s the CPU usage (upper right corner in VCV Rack? If it regularly exceeds 100%, you might run into trouble here and there?
For the cvly patch it is running average 123% and I’ve seen it top 200% a few times. The worst offending module appears to be Basal running close to 20% in this patch. Actually, Bleak is in there at about the same rate as well.
Try and press F3, to get performance info per module. This process requires extra computing power for itself to work, so pressing F3 might temporarily make things worse, which in itself will tell you there’s a lack of processing power.
** How many threads are you allowing? 1, 2, 3 or 4 (or even more) threads? More threads can spread the CPU load (but more is not always better)*.
I have stayed with 1 since the outset.
What sample rate are you running at? 44.1Khz, 48Khz, 96Khz, 192Khz or other?*
I try to keep it at 44.1 and 128 buffer just because I frequently use VCV Rack in Ableton along with keyboards and other controllers so I need to keep the latency down.
** What buffersize is set. 64, 128, 256, 512, 1024 or other bytes? Smaller buffers, requires more computing power.* (128-256)
What (GUI) framerate are you running. Higher rates, requires more computing power.
I’ve been using 60. Turning it down to 30 changes nothing in this patch.
As an experiment I bypassed Basal and Bleak which lost me two of five voices got the CPU avg down to around 75-80% - peaking a few times up around 135%. Yes, the remaining patch sounds a lot better - no distortion really at all.
Basel and Bleak running at 20% each? That doesn’t sound right. I don’t know the patch, but are they running polyphonically? I would also up the buffer size to 1024 (or more if you don’t notice any latency) and take the frame rate down to 20 to ease the CPU load. If you are still having audio hiccups then allow more threads. Your audio interface should also have an option to up the buffer size and should be set it to be the same as Racks.
Basal gobbling up some 20%, running 9 polyphonic voices with modulation (so, effectively 9 ‘copies’ of Basal).
Bleak running at a pretty usual 1.5%
This is on a many years old Intel i7 laptop at 48 Khz/30fps/512 bytes buffer/2 threads.
Running this patch using a single thread makes my laptop struggle and stutter with CPU load way above 100% most of the time. Two threads sort of half the CPU load. Allowing more then 2 threads does not really further improve perfomance for this patch.
I didn’t download the patch, but I did put up three VCOs all running 9 voices. As you might expect, the nice Vult modeled one uses a lot more than the others, but I wouldn’t say it’s a “cpu hog”. I think this show the importance of understanding how the meters work in VCV, and perhaps on top of that when one is making patches you need to think about your CPU budget. Maybe in some cases not every voice needs to use all heavy modules? Of course one runs into the same issue in a DAW with how many VST you can use in a session. Oh - and of course notice that the Squinky Labs Basic VCO uses almost no CPU.
