Apple Silicon M1, first system-on-a-chip for Mac computers

I was curious so I ran the test-patch-06 on my 2020 iMac.

27" Retina 5k, 3.8Ghz 8-core i7, Radeon pro 5700 XT 16GB, 64GB RAM

With one Rack thread audio broke up / crackly.

With 2 Rack threads, plays fine over time. Activity Monitor shows 235% CPU and using 11/12 CPU threads. 15.5% GPU (Framerate is max 59Hz). Fan not on at first, but came on after a few minutes but very quiet/gentle.

2 Likes

Yup, that’s the interesting bit. The CPU might not be far away from thermal throttling. You might not be able to run a patch much larger than test-6 on your machine, at comparable settings. Interesting test, thanks!

1 Like

Yeah at lower frame rate and higher VCV Rack engine threads, i can double the patch. But the fans at that level will probably make it fly out of the apartment, so yeah :rofl:

I think i will have try and be patience for the MX / M1 pro , and then for the first time ever switch to Mac platform for DAW purposes. Interesting totally didn’t see this coming, but i was lately very charmed about the capabilities of my iPad pro. So maybe that was already a hint for me.

1 Like

Nice. Suggests that your machine has more headroom to run Rack than the M1 Air, which one would hope at the price difference. Would be interesting to know how many more rows of Dexter voices you could add to that patch, and still have it play well after half an hour, without you being nervous of impending meltdown :slight_smile:

test-06.vcv:

  • Windows 10
  • AMD 3900X (stock) / Memory 3600MHz
  • Nvidia RTX 2070 Super
  • Clock 44.1KHz / Buffer 1024
  • VCV Frame Rate 50Hz

results:

  • 2 threads are required to run all 6 Dexter rows
  • Global CPU usage - 7-8% (VCV minimized) / 9-10% (VCV active window)

This has the makings of a big win for Apple, it must be said.

While the first product offerings don’t have the overall power of today’s high-end PCs, what those new machines are doing with what they have is very promising. And all of this through an x86 translation layer…

I’ll be keeping my eye on the benefit gained by moving DSP to native M1. And a reputable report has arrived (https://www.bloomberg.com/news/articles/2020-12-07/apple-preps-next-mac-chips-with-aim-to-outclass-highest-end-pcs?srnd=technology-vp&sref=iLKHMuSw) raising the possibility of 32-Firestorm-core Mac Pro in 2022. If Apple resist the temptation to slap eye-watering premium prices on their top line, they could clean up in the power-user sector.

1 Like

@LarsBjerregaard - just for fun i gave your test patches a try on a raspberry pi 4b running my 64bit arm build of vcvrack via my sonaremin linux setup and i’m getting up to test-04 which is still running well on a non overclocked rpi (i.e. 4x1.5ghz cortex a72 cores) at the sonaremin default sampling rate of 32khz (buffer 1024) with either the internal audio headphone jack or a usb audio interface - it is running then with two cores using about 85% cpu each … this of course cannot really compete with the apple m1 but on the other side is not too bad for such a little less than $40 device - maybe with overclocking to 2ghz (which most of the rpi’s usually can handle well) and some pushing even test-05 might be possible :slight_smile:

best wishes - hexdump

update: btw. no fan kicked in as there is none in my setup, just a big passive heat sink - it runs stable forever at about 55 celsius this way

4 Likes

My experience w surge

  1. Dual compile. You can do this on an intel mac no problem don’t need Apple silicon. We do it on machines in azure.
  2. Get the two binaries and glue em together with linker. Xcode does this automatically but it’s just calling linker commands
  3. Done

In surge we use cmake; it was literally a flag to do this and then all our binaries were fat. We of course had to sub out our sse code but had that already since we ported to pi. Folks here and elsewhere report an arm daw picks our arm side binary.

1 Like

Where does the heat from the copper go? Most laptops I’ve looked at use a heat pipe to a copper heatsink, and a fan blows through the heat

I think you forgot the step where you test it to make sure it still works?

it is a huge one piece copper thing, that is nearly as wide as the laptop. With tubes and shapes, and has 2 fans built-in. From what i can remember seeing, last time i opened it. And at the back of the laptop there 2 huge grill openings.

Despite all of this, it can still be a jumbo jet when passing the 50C

Ha yes of course. It helps like I said that we had a full pi 64 bit port and volunteers who tested it here and elsewhere

2 Likes

Hi all, and a happy new year! May the force still be with you in 2021! :wink:

Well it turned out that my arm64 port turned into it’s own experimental project… While optimising and rewriting some parts of Rack, I was not able to resist bringing in some of my own flair and ideas and now that happened:

Beneath optimising some stuff I added a frame buffer cache for all graphics for super-fast-redraw-monster-power (with the drawback of higher RAM usage, but hey…) so I was able to use complex vector graphics like the rail bus board and other stuff. I also changed some of the UIs (colours, fonts and shapes) a bit as you can see… I call it: ‘RACKSPERIMENT’ - It’s just for fun and research.

The code is not complete on git and there is currently no downloadable version, but this will follow, if you’re interested.

Cheers, Patrick

10 Likes

And with some additional analytics section for GPU and CPU usage:

7 Likes

Awesome! Good to see you have some positive progress with your ARM build fork.

I have a M1 Mini 16GB arriving soon, might be knocking on your door soon for a test build :wink:

2 Likes

That sounds really interesting Patrick. If you think this is something that could be cleanly generalized to Rack proper, I would encourage you to engage Andrew on Github with this solution, so we could all potentially enjoy better graphics performance in the future. That would be swell!

3 Likes

Hi Lars,

well, I don’t know what happened in v2.0 already, but that is a good hint. If I finished uploading and preparation of my experimental version on git, I will think about this.

Cheers, Patrick.

1 Like

As far as I recall Andrew was mentioning graphics and other optimizations for v3, so your input could potentially be vary valuable for v3.

This might also benefit some slow non arm machines, will be waiting to try it out if you push source to git.

Today I updated all sources and I also added a small change-log on GitHub:

It may also work on non arm Mac’s - all UI and other non architectural depending changes could be merged into a current standard 1.1.6 Rack build. Somebody may try it :slight_smile:

I hope it works if you update… I didn’t try - if you have questions don’t hesitate!

Cheers, Patrick.

2 Likes

So I finally got myself a base model M1 MacBook Air, after a lot of indecision. I wasn’t sure whether to get the 16GB RAM version, but I needed something cheap for work/study. I’m only fairly new to VCV and music production, and I realised that from everything I’ve seen the base 8GB air should fulfil my needs for now (which sounds crazy!). I plan on getting an M1 mini at some stage this year if the rumoured ‘pro’ version comes out.

So far in my moderate use I’ve encountered no issues at all, and it’s actually crazy to be able to lay in bed with the Air propped on my legs working on ambient patches. Coming from a mid-2012 MBP that struggled beyond three voices this is a revelation.

2 Likes