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.
@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
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
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…
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
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!
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.
Same here
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
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
- Quality of/ability to mix and master a recording.
- Quality of DAC/audio interface, cables, etc. etc.
- Samplerate, bit-depth.
- …
4 Likes
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. . .
@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
@LarsBjerregaard, so, now I am confused how the rack engine sample rate really works and how it all ties together.
From our conversations a year ago, with you, @Squinky @gc3, I thought I had a handle on it. In Rack v 2.06, are you saying, it works differently than v1.16? I ask, in response to your comment in the other thread, regarding setting to Auto, is best, and best for cpu loads… etcetera.
Is this why I’m getting noise on (especially) poly output? Changing Sample rate / Block Size / Number of threads has zero impact.
Mac Monterey 12.2.1 ; 3 GHz 6-Core Intel Core i5
@ScreenSlave first, can you quantify noise? :- ) I am not trying to be snarky, but can you be a bit more specific regarding the type of audio anomalies you are hearing?
Secondly,
Please, let’s keep this narrow - I was speaking only to how the Engine samples settings work with Audio Interface sampling rate - How do they team up. If you read above, last year I wanted to dig into this terminology and how it works, that was v1.16. (see noted thread above) I brought up a situation, and yesterday, @LarsBjerregaard spoke to keeping it set to Auto since it is kinder to most cpu load and mentioned why. This causes me to pause thus asking the question here, again. I personally, am not seeking it kinder to cpu, and it counters what we talked about last year. Which then begs to question, in v2.0.6, does the Engine settings have a different implementation then v1.16. How the two work together…
Look at your settings, are you running ASIO … wait you’re on a macOS, I am on Windows so I cannot speak to your situation. Apologize. I have zero idea how Rack looks even on macOS. Are you keeping the engine on auto or = to your audio device sampling rate? It is highly likely it is different in the mac world, so I do not know. Honestly, there can be a lot of things causing your particular issue, and more digging/clarification will be needed to resolve.
Sure - I am hearing what sounds like distortion where the sound is breaking up and becomes bitty, even at low volumes and through the internal speakers or external speakers via a preamp.
I have tried it with auto and setting from the list to match the sample rate on the Audio module.
The difference with the MacOS is possibly to do with how multithreading works with the (in my case) 6 cores in the processor. I am not sure if this is the cause of the distortion I am hearing.
Is it possible this is the same issue as the other thread - excess CPU usage? What is they CPU usage? Do you have rack set to the default number of cores (one)?
I have it set to 3 cores which gives CPU avg / max around 60% - when I set it to one core (or 6 cores) the CPU avg / max goes over 140% and it sounds really weird.