Both actual practicing musician subjective opinions as well as basic DSP theory 101 are welcome in response to this. It’s important to know theory, but occasionally how it tends to work in practice can be more valuable than theory.
All else equal, would you say choosing higher engine sample rate is generally better? Or is it true only for particular music/signal path styles?
There’s a reason some modules offer oversampling: in some scenarios it’s beneficial, even if it consumes more CPU.
Can it be beneficial to set higher engine sample rate than my audio hardware supports, for some sort of global oversampling? Sure, it means audio would be resampled before I can hear it, but presumably this wouldn’t affect what’s recorded to a file, while running the entire engine at 2x higher sample rate can offer benefits in terms of less aliasing, etc.?
My currently plugged in hardware is limited at 48k, and I developed a patch with that. I tried 2x’ing engine sample rate to 96k, and immediately noticed a change in how my patch sounds, at least the behavior of high/low pass filters (illustration below).
Without carefully vetting every module that it retains behavior with different inputs under different sampling rates (which is barely feasible), does this mean that later, when I switch to 96k+ hardware, I would not be able to use that sample rate if I want my patch to sound the same? I should make sure that if I plan to perform I use the exact sample sample rate as when developing the patch?
Here’s a simple circuit illustrating how filters change their behavior. This is MUS-X filter set to 24db/oct LP mode, no oversampling (in fact, setting different oversampling rates on my filters in my patch did not cause perceptible changes, only changing the global engine sample rate unexpectedly did). I restarted Rack every time I changed sample rate to make the experiment more clean.
Long story short: When you feed a complex signal into a non-linear circuit, you get something called Intermodulation Distortion (IMD). It’s easy to observe, send a single sine wave into a distortion, look at the output in a scope. You’ll see new harmonics have appeared. Now send two sine waves at different frequencies. You’ll see not just the harmonics of the individual sines but also other ones (at the sum and difference frequencies between them).
The main reason to increase sample rate is to mitigate aliasing in nonlinear processes. Aliasing can sort of be understood as a special case of intermodulation distortion. Say your module adds a harmonic at frequency 200Hz above the nyquist ceiling (samplerate/2), that harmonic will instead be heard at nyquist - 200Hz.
Oversampling is an effective way to lessen that problem. But be advised if you run your whole project at 192Khz, there are now several extra octaves above the normal nyquist, which modules may end up filling up with all sorts of noise. That noise will itself be inaudible, and when it reaches the final downsampler at the output it will be filtered out anyway, but if you run non-linear processes at the higher sample rate you will get IMD between that treble noise and your actual audible signal. That IMD may negatively affect your sound (in a similar way that aliasing does, though the phenomenon is separate), so you may want to avoid it.
One solution is to only oversample the modules that need it. Another option is to put steep lowpass filters just at the edge of the audible range before every distortion/non-linearity in your chain. Both of those methods work perfectly well. But the former tends to be more efficient, so that’s what I’d recommend. I’d use the latter method only if I really wanted to use a module which sounds better at higher sample rates, but doesn’t have its own internal oversampling
Evidently yes, it can be. As you’ve observed, VCV can run its internal engine at a different rate than your audio interface and down/upsample at the end of the chain.
As per the above though. You may prefer to only oversample the things that need it. If possible.
3: The internal sample rate in VCV is what determines the way your patch sounds. If you want to be 100% sure that it sounds as intended, then yeah, use the same samplerate consistently. As you’ve shown in point 2 above, the samplerate your interface expects doesn’t seem to affect that. And in any case, why would you go to 96k at the output stage? Unless you have one of those soundcards with built-in DSP, it won’t make a difference.
Ideally every module should strive to sound similar at all VCV sample rates, within the constraints of what is possible for a given sample rate. Obviously lower sample rates cannot reproduce higher frequencies. Some modules do better than others with consistency.
But the noise seems to be particularly sensitive to the sample rate, and the VCV violet noise is dramatically different between 48kHz and 96kHz. I checked a bunch of noise modules, and all of them sounded distinctly different at 48kHz vs 96kHz. In general, the 96kHz tended to attenuate the sound. But there were additional differences, depending on the module and type of noise. Maybe there is something inherent to noise generation algorithms that make them particularly sensitive to sample rate.
And in any case, why would you go to 96k at the output stage?
I guess if I run VCV at 96 kHz and I have an interface with 96 kHz when performing, I might as well use that rate simply to avoid unnecessary downsampling, but I get your point.
I know there won’t be audible difference between running audio output at 48 kHz vs. 96 kHz, but as I understand there may be audible difference between running VCV engine at 48 kHz vs. 96 kHz, where the latter may either be beneficial or detrimental and the only way to make sure is by checking how it is in practice.
Are you saying the difference in spectral image is caused by difference in behavior of VCV Noise module and not MUS-X Filter module? That’s an interesting point I have not considered.
This begs the question, if noise generation algorithms are sensitive to sample rate, then 1) where else are these algos used other than in the literal Noise module, and 2) what other algos are sensitive to sample rate.
Is there a good practical rule-of-thumb engine sample rate that is a good balance between IMD and aliasing?
Since vast majority of modules don’t offer user-configurable oversampling (which I presume means they don’t oversample(?)), how many of the commonly used modules may benefit from higher engine sample rate—especially those typically used closer to the beginning of signal chain, where if I understand it correctly aliasing is the most problematic?
Ignoring is one thing, subtle behaviour differences is another thing. It was suggested in this thread that even a staple module like Noise changes its output depending on engine sample rate.
Someone with significant spare cycles may want to take a look at how the AudioPort does resampling. Under the hood the speexdsp resampler is used for sample rate conversion in AudioPort. It has a quality factor with values of 0-10 allowed. AudioPort sets it to 6. I don’t know what the effect of a higher or lower value has or if it would be worth changing (higher or lower).
Another thing worth noting is the speexdsp resampler is completely avoided if the audio interface and the engine are at the same sample rate (which makes sense).
Short answer: No. There are way too many factors to take into account.
You gotta make your own comparisons with your own patch. To deal with aliasing and related Nyquist-induced artifacts: Try different sample rates and compare. Use the lowest one that sounds fine to you.
If after having done that, you settle for an engine SR higher than 48k, You may want to deal with the IMD-with-ultrasonics issue. Put a 36 dB/Oct low pass at ≈20k before the most module in your patch that distorts the most. Compare results with/without. If it sounds better with the filter, keep it. Repeat as needed.
There are hundreds and hundreds of “commonly used modules”, so that last question is sorta impossible to answer. The doctor prescribes a healthy dose of “don’t worry about it too much” and if that doesn’t help within the first three weeks, follow up with a solid treatment of “understanding the fundamentals and applying that understanding to your actual situation”.
Jokes aside, I will again highly recommend watching all of Dan Worrals videos explaining this stuff, it’s worth your time.
Oh, and a lack of selectable oversampling doesn’t necessarily mean the plugins don’t oversample. The Surge VCO’s all run at 2x. I’m sure there are others who do stuff like that as well.
