The thing is, I’ve never found any case where more than one thread performs better than one.
The M1 Pro in my MacBook is considerably faster than the Intel 3.5GHz 6-Core Xeon E5 in my last music machine. What’s an example of a CPU that would be “up to” running multiple threads?
That’s my point. It doesn’t perform better, but more threads allow you to have bigger patches, to scale up by using more CPU cores. But only when you need it.
Are you saying it shouldn’t glitch like in my video above, once I bump up to two threads?
As it is, I’m still having trouble seeing any use case for > 1 thread, at least if it’s going to always glitch like that.
According to Activity Monitor, the above patch uses in the low 70% of a CPU when idle, a bit over 250% of a CPU when playing on one thread, and around 370% of a CPU when playing on two threads (with significant glitches.) The processor I’m running on has 8 performance cores, and two efficiency cores
This option was introduced before the existence of M1, M2, M3 mac OS. And for windows PC’s it works just fine…when it starts crackling, add a core/thread. I think M1-M3 handle the load internally and changing the threads have no positive result whatsoever. I think this option has no use for a mac ARM user.(Just keep it on 1) X64 on the other hand could benefit from is ?
I can confirm that for me, on Windows X64, 4 threads is the best setting (except for small patches where it’s not needed and doesn’t matter). For my usual (medium) patch size it’s getting worse if I reduce the number of threads but also if I increase it. Now, I have 4 physical cores (8 logical cores), I don’t know if that’s the reason why 4 threads appears to be optimal for me. But yes, maybe Mac is a different story.
I’m pretty sure it’s not.
Well, something must be different, either with the M1 Pro processor, or the OS, that renders using a VCV Rack thread count > 1 pretty much useless (at least on my machine.)
An example of a case where I would love to be able to use >1 thread: In many of my patches I have an NYSTHI PolyRec64 so that I can save stems from my patch to mix in an external DAW. This seems like a fairly good candidate to be running on a separate thread, as it has to do a bunch of disk writing. As it is, I usually get some glitches coming out of the headphone jack while recording with PolyRec64 (w/ a single thread) but they aren’t in the recording. The glitches do make the process of interacting with Rack while recording pretty unpleasant, though.
I agree, on the M* processors 1 thread is the only good setting, the OS will still schedule threads across all cores as needed. Seems to work fine, rarely come up to CPU limit (make sure web browser is quit though, they tend to cause crackles and hiccups when they do who-knows-what even if they are in the background and not visible).
Disk writing should never be done on the audio thread. That would be terrible. A lot of nysthi modules spin up a separate worker thread, which would not be any of the audio threads.
Don’t M1 CPUs have different kinds of cores, like slow ones and fast ones?
(yes, it does, I just checked) " The M1 has four high-performance “Firestorm” and four energy-efficient “Icestorm”"
Maybe then your run multi thread, rack isn’t smart enough to avoid the slow cores and you end up picking one of those?
nah, mostly uses fast cores, the os will chose slow cores for background tasks, at least by what I checked. Not scientific of course…
I asked teh internet and got a different answer. Does the number of threads available in VCV give a clue? I can’t check that - I only run VCV on my Intel Windows machine. I think the M1 has 4 perf cores and 4 efficiency cores? So I’m hoping VCV only goes up to 4 on an M1?
RTAudio site doesn’t say anything about this, which is odd.
looking at the CPU meter (part of the activity monitor app) I see mostly the 4 perf cores in use when Rack runs (1 thread set), the OS seems to use the efficiency ones when it needs to do background service for Rack, and itself. Again, not scientific. And this is my work and play machine, never an issue. I have not yet made a patch that would make me see if a second thread would make a diff, so shrug, one thread in Rack set and leave it. Works even with the monster Airwindows patch that Dave made as a stress test, doesn’t go above 80% CPU and never crackles or skips… The only thing that I ever saw making the CPU go over 100% is the VCV Convolver, that thing is CPU hungry, a second thread just made things worse, due to MT overhead. So no point to raise it methinks. Your mileage may vary.
The M1 in my computer has eight performance cores and two efficiency cores.
I searched the Rack source, and there is nothing Rack does to control the thread cpu affinity. All the platforms have APIs for it, and presumably ways to query which cores are “efficiency” cores. I’m guessing if an app doesn’t do anything explicit, the OS will schedule threads to the various cores as it sees fit, which may not be optimal for this use case.
When we start getting usable ARM Windows, we’ll start to see more of similar questions on that platform.
BTW the RT* libs used by Rack are at least a version behind, and I think these versions precede the existence of the M* chips.
Is anyone using an M1 machine able to record video, using the VCV Rec module?
M2 macbook pro, here, it is not working.
Use blackhole, make a multi output device in Audio Midi Setup with blackhole and your usual audio device, set the multi device as output in audio module in Rack and record with the blackhole input in quicktime, recording the Rack window, done, works perfectly
are you saying don’t use the VCV recorder?
I would say more like I can’t use the VCV recorder (for video.)
It just doesn’t work.