After reading Squinky Labs’ CPU message, I was playing with CPU levels and ran across something very strange. With the engine set for one thread and 44.1 KHz sampling rate, the Audio-8 module in my patch shows 1.3% CPU load. If I switch the sampling rate to 16x (768KHz), the Audio-8 CPU load rises steadily to well over 100%! And, this is without the patch generating any sound. The clock is stopped. Any ideas on what’s going on?
768kHz = 1/768000 = 1.3us per sample. Audio-8 is being measured by rack as taking 1.54us per sample, so is using 1.54/1.3 = 1.185 = 118.5% of the time available.
2 Likes
The Audio module is running all the time, taking samples, whether there’s any “sound” to sample or not, that’s how it works. Setting the sample rate to a monstrous 768KHz you found the limit of the performance of a single core in your CPU.
That makes sense, but how can the percentage be more than 100%? I guess the numbers are rough estimates and not to be taken too seriously.
Oops, missed rare.breeds message. 
That makes even more sense, at least mathematically. Since I can’t actually use high sample rates in any case, knowing how things work is all that’s needed. Thanks!
I guess it’s all in the nitty gritty details of the definition of “exactly what are you measuring”. As an example - on Windows the “process manager” shows the CPU percentage of a process as “the percentage of the entire CPU, all cores, that the process uses”, whilst on MacOS the percentage means “the percentage of one CPU core that process uses”, so on MacOS it’s common to see a process like Rack use more than 100%.
I confess to not really knowing or remembering, what the percentage measurement of the Audio module means anymore. It used to be clear but it was changed so…
1 Like
Right - the “percentage” needs to be understood. From rare.breeds’ math, it seems like it says “at the sample rate, you have this much time to complete the process.” Then the time the process actually takes is measured. The reported percentage is the second divided by the first times 100. Essentially, if a process takes longer to complete than the sample rate expectation, the reported percentage goes over 100. Makes sense once you think about.
1 Like
Yeah, I haven’t investigated but if that is indeed the algorithm, then as soon as you go above 100% you should start hearing crackles in the audio. Is that your experience?
Yes, that’s exactly what happens. I also noticed that adding threads causes the load to go up slightly, maybe 1% or so. That stills seems to help overall as I’ve picked up patches on Patchstorage that crackled with one thread and sounded fine with six threads on a six-core system.
Good. Yeah, that’s the idea. You start with one thread and only when the audio starts to break up you add another one, etc. Multiple threads in themselves have an overhead.
1 Like
Is that really true? I think all DAWs run with a ton of threads, as does most software.
Maybe I should have qualified it: Multithreading in VCV Rack has a CPU overhead.
2 Likes
It’s probably down to how VCV rack parallelizes things.
The Engine > threads drop down menu sets the number of worker threads. Then for each time step each worker races the others to pick a module and process it.
This makes it unpredictable which thread is processing which module. OS’s like to keep a thread assigned to a particular core where possible to avoid having to re-fetch anything that processor has cached for the thread. If you randomly pick the thread that does the work then you lose that benefit.
So I’m guessing the increase in cost is increased cache misses.