M1 Max Performance?

I did not know. I looked in the library and did not see.

Always quit any running browser, and anything else using background cycles that doesn’t need to apart from the music stuff. The multi thread issue may be due to first, the way the M1 handles threading, and second, muti-threaded programming, especially if essentially one thread needs to run near real time, is hard, to do right and efficient on any platform. You must make some pretty large stuff that you need more than one thread, I have a big mixmaster/auxmaster/eqmaster/bassmaster and compII cabled together for output mixing, never had any perf issues, even with all 16 minxer channels being used… This is on a plain old M1 Mini.

I’m using an m1 Mac mini and i can easily create patches in excess of 30 modules, and in some of those patches I’m using two MindMeld MixMasters, an 8 channel one for my drum bus and a 16 channel one for my main mix with the Aux and Eq expanders on each. I am set to 48kHz sample rate, a buffer size of 64 and set to use 1 thread. Our single core performance is pretty similar 1714 on my M1 Mac min and 1754 on your M1 Max MacBook Pro. How many and what type of modules are you using to get to 90% of a single thread I have created some pretty big patches and yet to go over about 60% cpu usage. Also what is your buffer size in the audio output module set to.

That is quite a low buffer size. I generally run at 256 for example.

But I did see your other thread where you said as you reduced buffer size, CPU usage actually went down rather than up which sounds a bit odd…

It would be interesting to see if you get any better ‘real world’ performance (rather than just looking at the CPU meters) by changing to say 256.

I don’t know what my real world performance would be , I could try adding as many modules as I can with a buffer size of 256 and see if the same thing happened when I then lower the buffer size, but I cannot see the point in wasting time doing that . I run out of ideas in a patch before I reach any problem with the number of modules I can use with the buffer set at 64. Their is also another reason I use a low buffer size, I incorporate my Elektron analog keys into most of my patches so keeping the latency down is important to me.

This is when running clean, without other processes running. I tend to favour some of the heavier modules, like @modlfo Vult filters and distortion. I’m working in quad as well, which means quite a few channels of polyphony and many utility modules as soon as patches grow beyond a few sources. I’ve gotten quite good at optimizing patches for low CPU usage, but needing more than one thread is a situation I’m commonly running into.

Seems a shame to be limited from using all the other cores available in these chips.

While it’s running under Rosetta2 there is little anyone can do, and an M1 native build is not likely until all libs Rack depends on are native as well… Plus that will add another 3rd of support burden to go from 3 to 4 supported platforms. More likely to happen by the time Apple no longer supports anything with an Intel chip inside, as then it is not another platform to support. So you sadly fall between a rock and hard place. I would put a vote for an M1 built into an email to support at vcv. I guess if enough of us add our vote it may add some urgency to get a native build rather sooner than later…

Just a stupid idea that probably won’t work but if you have the pro version of VCV rack it might be possible to have another instance of VCV rack running as a plug in host thus, as far I understand it, running on another thread. I haven’t tried this as my patches are not that big but it might be worth investigating.

1 Like

That is an intriguing idea. Unless there is some M1 architecture constraint that gets in the way, I think you should be able to set the block size quite low to get extremely low latency.

I’d like to add my own experiences to this thread.

I’m getting very glitchy audio form VCV Rack 2 when running on both M1 Max MacBook (2021, 32 Gb RAM, 10 cores) as well as Intel Mac (2017, 3.4 GHz i5, 32 Gb RAM). The glitches are crackles and stutters, much like the OP describes.

Some more details:

  1. Glitches appear whenever the single-thread CPU usage is about >50%. In other words, when the patch is small, multi-threading (e.g. using 5 out of 10 threads on the M1) works fine. However, as soon as my patch uses significantly more CPU in single-thread mode, putting Rack in multi-thread mode glitches.

  2. Nothing else is running on the Mac, freshly rebooted. I’m using the built-in audio chip. There’s plenty of memory, so that’s not an issue.

  3. Running at 20 fps and 48 kHz sampling. Frame rate seems to impact performance negligibly. Changing sampling rate has no effect on the stuttering – as soon as multi-thread mode reports >100% CPU usage, stuttering happens.

  4. Glitching occurs regardless of block size setting in Audio module.

  5. My patches are relatively complicated and I’m using a lot of modules, including the MindMeld MixMasters, which were mentioned in this thread. I’m managing to run at about 95% single-thread CPU usage without glitching (e.g. on the M1) but it would be fantastic to be able to kick into multi-thread mode to have some headroom and opportunity to expand the patch.

  6. The 3.4 GHz Intel is about 40% slower than the M1 (e.g. for my patch, single-thread Intel usage is ~160% where M1 usage is ~95%).

Sounds like you have an underlying problem that has nothing to do with threading. Also sounds like you’re using threading wrong. Try and look here if anything helps:

Thanks for linking that post. I read through it and it looks like I’m already following the points brought up in that post that are relevant to using VCV on a Macbook Pro (e.g. I can’t switch to a different graphics card, but I can lower fps, etc).

I do wish it was some “underlying problem” but, honestly, I can’t see what that could be. It’s a clean Mac OS install on a new M1 Macbook Pro, which runs like butter with everything else.

I’d love to hear reports (and their setup) of someone running VCV Rack on an M1 Macbook Pro without glitches when using >1 thread on a patch that uses >100% CPU when only one thread is enabled.

On this Chromebook arm64 I dropped View > fps to about 20, and run 2 threads so I can also not interrupt the YouTube. It does 48 kHz, and although only a few modules, doesn’t really under run if I don;t move or zoom windows. Are you sure the Rosetta layer isn’t JIT compiling the future just when you’d like to have the code all runny? Mac arm64 is beta, perhaps it will get better.

Here’s what I’ve managed lin-arm64 so far VCV - Google Drive and there is likely more. The tool chain on Mac although different should be able to out perform this 8 core with 2 GB on the virtual linux container.

No glitches 2 threads. Picture in picture and all sound plus occasional drone beat to test.

Here is top aliased to htop

And what the main google tool thinks

And battery says

Although if I play audio books and the screen goes off I can get over a day.

1 Like

That’s excellent performance. Makes me hopeful for playing with VCV on a Pi4 (or its successors).

As for Rosetta, AFAIK it does a complete trans-compile of the entire code on first load. I’m not sure how they handle plugins—though the performance drop has more to do with a lack of threading than any intermittent performance drop.

FWIW the VCV 2 beta Arm builds run very fast with no threading issues.

1 Like

@LarsBjerregaard has had excellent results running under rosetta on an M1.

I think we all do. I’ve read many people now on this forum that couldn’t be happier with the Apple Silicon machines and Rack. So I think there’s something else going on here. @dlphillips did some informal comparisons on his M1 machine suggesting, that for the Rack case and its plugins there’s only a roughly 5% performance difference between Rosetta and native.

1 Like

Rosetta performance is great on M1! Performance is also great on M1 Pro and Max—as long as you stay under a single thread. With M1 Pro and Max, multi-threading in Rosetta mode with VCV has several issues (it’s a known issue, dialogued with VCV Support, and fixed with the upcoming Arm builds).

1 Like

Interesting, first time I’ve heard of that. So only an issue on PRO and MAX CPU’s and only when using multithreading?

No, my base level M1 MacBook Air also runs great under Rosetta as long as I stick to 1 thread. But it cannot handle VCV configured for multiple threads. In general I haven’t needed more than one thread. But If I want to run at very high sample rates to reduce audible aliasing introduced by FM or wave folding etc, then sometimes I wish I could use multiple threads. That is why I am looking forward to a native ARM release, hoping that it can handle multiple threads and thus allow me to run moderately complex patches at higher sample rates.

1 Like

Yes it appears to work fine on lin-arm64 but with compiling your own modules as the library issue takes a build target to allow for architecture specifics. I mean M1 should be easy as arm7 vs. arm8 is quite sorted. The lin guys can usually CLI a compile anyway, and GUI simplicity is not often a complete deal breaker for them.

I haven’t run the mac arm beta. How’s it go with the library not using make run but ./Rack?