I’m using an M1 Mac mini solely to run VCV rack. Under Rosetta it seems to be running extremely well, I’m using macOS 11.6.8. When the default patch loads it defaults my audio interface, a MOTU M4 to 256 samples and the CPU is taking around 6% . When I change the buffer size the following happens. 128 samples 5.2% 64 samples 4.6 % 32 samples 4.2 % 16 samples 4.9 % As my patches get bigger, round about 40 modules 64 samples seems to give the best performance. . My number of threads in VCV rack its set to 1 and a sample rate of 48kHz. and my interface is using MOTU’s proprietary Core Audio driver not Apples one. When I look at Apples CPU meters it shows 1 Firestorm ( high performance ) core with a small amount of activity with the rest of the activity shared between the 4 Icestorm ( high efficiency ) cores. I’m just wondering if any one knows why this is happing as normally decreasing the buffer size causes cpu usage to go higher.
We’ve seen this from https://help.ableton.com/hc/en-us/articles/5266527910812-Reducing-the-CPU-Load-on-an-Apple-Silicon-Mac
How to Optimize Live’s Audio preferences for Apple Silicon vs. Intel Processors?
The relationship between real-time audio performance and buffer size changed with the introduction of Apple Silicon Processor’s architecture.
On Intel-based CPUs the following relationship in Live is as follows:
Smaller buffer sizes may result in higher CPU usage
Larger buffer sizes may result in lower CPU usage
Contrastingly, on Apple Silicon CPUs:
Smaller buffer sizes may result in lower CPU usage
Larger buffer sizes may result in higher CPU usage
It does say further down that: Note: In some case with certain CPU intensive processes, lowering the buffer size will not reduce CPU load. In that case it might be better to higher the buffer size. In addition, consider the following article for techniques to reduce the CPU usage of devices and plug-ins.
Interesting! and quite counter intuitive… Generally lower buffer sizes are seen as more desirable with less latency, so being able to make your buffer lower AND decrease CPU at the same time seems remarkable.
I wish they could do something similar with wine…
"Previously, the more money you spent, the better wine you could buy, now however… "
I was just testing this on a Mac Mini running 12.5.1, Rack Pro 2.12 standalone, no browser or other apps running. Makes NO difference for my AudioBox USB (stock CoreAudio ) whether I have buffer at 256 (my normal), or 128, 64, and goes higher with 32 by a couple of percent. So cannot reproduce this. Patch was riding at about 38% CPU as per CPU meters in Rack, so not heavy, 1 thread given to Rack.
Cheers for your input man I’ve read that article and it seems to back up in part what I am seeing. I think the reason I’m not getting problems with lower buffer sizes is that I use an external instrument, an Electron analog Keys for most of my voices and also only use drum modules, sequencers and mixers and VST 3 effects in most of my patches. If I understand it correctly my VST effects using VCV Host run on a different core to VCV Rack and don’t impact the resources of VCV rack. Also the reason I use a low buffer size is to reduce the latency of my Electron device. I also set Host’s buffer size to 64 samples as well. I tend to make my own brand of minimal psychedelic Techno based loosely around Steve Hillages System 7, who I have followed since his early days with Gong, which tends to be drum and effects heavy.
I used the default patch so that other people if they wanted to try this would be using the same starting point. When I am running a larger patch changing the buffer from 256 to 64 samples the CPU load remains pretty content only increasing when I try to use 32 or 16 samples. I have no idea what the effect of using MOTU’s proprietary driver has although I do know that it reduces the latency by about 1.5 mS compared to Apples Core Audio driver at a buffer size of 128 samples.
Whoa, that is one heck of an optimization, seems odd, Apple’s CoreAudio is known to be extremely low latency and highly optimized. Must be the only company that had to roll their own?