Diva with Rosetta2 on Apple M1

Official support for: u-he.com
Post Reply New Topic
RELATED
PRODUCTS

Post

Since many of you are curious (we, too) about the performance of the new Apple Silicon M1, here are the results of our very first test on the M1 MacBook Pro.

This was just a quick, unscientific "it's late at night but I can't wait any longer and need to know how good it is" test, but since the results are more than promising, we thought we should share them with you.

Test setup:

* Apple 2020 MacBook Pro M1
* Reaper, native Silicon beta
* 48kHz, buffer size 512 samples
* Diva 1.4.4, rev. 9709 (no ARM support), running bridged via Rosetta2
* "BS Deep Space Diva" preset (accuracy: great), playing six voices

We simply duplicated the track again and again, until the CPU bellyflopped.
And to have something to compare it to, we did the same test on an old, trustworthy MacBook Pro from 2015 with a 2.2GHz Intel i7 (this is starting to feel a bit like on an episode of Mythbusters).
Diva_Reaper_Rosetta2_M1.png
Results:

Multicore option in Diva disabled:

On the 2015 Intel MBP, 3 instances with 18 voices ran without glitches. The fourth instance already produced too many dropouts to continue working.

On the 2020 M1 MBP, 20 instances with 120 voices ran glitch free. With one more instance and 126 voices, there were some dropouts, and it finally glitched heavily when adding instance 22. :o

Our jaws dropped collectively at that moment.

With Diva's multicore option enabled in each instance:

On the 2015 Intel MBP, six instances with 36 voices ran glitch free, a seventh instance produced occasional dropouts, and the eighth instance brought it to its knees.

On the 2020 M1 MBP, only five instances with 30 voices played without glitches, the sixth instance already produced heavy crackling.

This is not exactly the result we were hoping for, but we are still in the process of porting our plugins to run natively (i.e. without Rosetta2) on the new Silicon chips, and we expect to see some better numbers by then.

Otoh this first test indicates that on those amazing new chips, there seems to be way less need for a multicore option than on traditional Intel chips.

I'm sure we will conduct way more tests, but right now we are simply elated and relieved to see our plugins performing so incredibly well under Rosetta2.

Rest assured, after these initial results, we are more motivated than ever to port our plugins to the new Silicon platform. Please be patient, though. The porting will still take quite some time, as it turns out to be more complex than anticipated.

Update December 8:
We now have a first version running natively on the M1 (i.e. without using Rosetta2).


With this version, we ran the same test project again, and could now run up to 32 instances of Diva with 192 voices without dropouts.

A word of caution about those numbers: This was just a very simple lab test, running the same preset, playing the same notes in each instance.
It remains to be seen how the plugins actually perform in real world projects.

We also have a hunch about the weak performance when using Diva's multicore switch, and we hope to improve this over the next weeks.
Cheers,
Tas
You do not have the required permissions to view the files attached to this post.
Last edited by tasmaniandevil on Tue Dec 08, 2020 3:46 pm, edited 3 times in total.
That QA guy from planet u-he.

Post

this is quite an unexpected result. what does the multicore option do, exactly, to create such difference?
I don't know what to write here that won't be censored, as I can only speak in profanity.

Post

Spreads voice processing across multiple cores. Guess the way it works for x86 CPUs is not fully compatible with ARM, at least not the translated binary, and would need manual code refactoring for ARM NEON...

Post

Apple has recently published a special method for audio plug-ins to make use of multithreading. Support for this is part of our porting process and that's why we expect much better multicore results once we have native versions.

Post

In REAPER: Preferences > Audio > Buffering

Playing with these settings will drastically change the way u-he plugins consume CPU and spread across cores. When I upgraded my PC form 4-core 3770K to 16-core 3950X I noticed almost 0 (zero) difference in my projects with mostly u-he synths. But after experimenting with Audio Buffering settings in REAPER, I was able to get some impressive results. The point is, those settings in REAPER are very important for any comparison test involving u-he synths :)

Post

Those results with multi-core off are mind boggling... and that is with Rosetta! Imagine the results with native Diva!!

By the time Apple releases a 16" MBP and an AS iMac, plus native u-he plug-ins are available, multi-core might no longer even be needed!

Post

Urs wrote: Thu Dec 03, 2020 4:00 pm Apple has recently published a special method for audio plug-ins to make use of multithreading. Support for this is part of our porting process and that's why we expect much better multicore results once we have native versions.
Keen to read more about this, are there any links you can provide?

Post

mustgroove wrote: Thu Dec 03, 2020 4:54 pm
Urs wrote: Thu Dec 03, 2020 4:00 pm Apple has recently published a special method for audio plug-ins to make use of multithreading. Support for this is part of our porting process and that's why we expect much better multicore results once we have native versions.
Keen to read more about this, are there any links you can provide?
I think this is the video I saw:

https://developer.apple.com/videos/play/wwdc2020/10224/

Post

My old friend Doug from Opcode days!!!!!.. Great to know he is still with Apple.

rsp
sound sculptist

Post

drzhnn wrote: Thu Dec 03, 2020 4:08 pm In REAPER: Preferences > Audio > Buffering

Playing with these settings will drastically change the way u-he plugins consume CPU and spread across cores. When I upgraded my PC form 4-core 3770K to 16-core 3950X I noticed almost 0 (zero) difference in my projects with mostly u-he synths. But after experimenting with Audio Buffering settings in REAPER, I was able to get some impressive results. The point is, those settings in REAPER are very important for any comparison test involving u-he synths :)
this

Post

And there is me getting glitches after ONE instance of Diva on my iMac runnign Ableton.

Surely there is something not quite right here since you can now run 20+ instances from a bloody MacBook... maybe I should contact DIVA support :(

Post

drzhnn wrote: Thu Dec 03, 2020 4:08 pm In REAPER: Preferences > Audio > Buffering

Playing with these settings will drastically change the way u-he plugins consume CPU and spread across cores. When I upgraded my PC form 4-core 3770K to 16-core 3950X I noticed almost 0 (zero) difference in my projects with mostly u-he synths. But after experimenting with Audio Buffering settings in REAPER, I was able to get some impressive results. The point is, those settings in REAPER are very important for any comparison test involving u-he synths :)
Which settings did you end up with?

Post

EvilDragon wrote: Thu Dec 03, 2020 5:45 pm
drzhnn wrote: Thu Dec 03, 2020 4:08 pm In REAPER: Preferences > Audio > Buffering

Playing with these settings will drastically change the way u-he plugins consume CPU and spread across cores. When I upgraded my PC form 4-core 3770K to 16-core 3950X I noticed almost 0 (zero) difference in my projects with mostly u-he synths. But after experimenting with Audio Buffering settings in REAPER, I was able to get some impressive results. The point is, those settings in REAPER are very important for any comparison test involving u-he synths :)
Which settings did you end up with?
For my particular needs I ended up with this (for Diva with MC mode enabled):
reaper_iTqWv9OvgK.png
You do not have the required permissions to view the files attached to this post.

Post

Neat. BTW you can probably reduce the render-ahead time to like 100 ms (200 is EXTREMELY generous), and absolutely enable "Allow on tracks with open MIDI editors" - it helps if you have a lot of things open in MIDI editor (say if you use one MIDI editor per project), and tracks send to other tracks with heavy processing chains. Going down to 100 ms also makes the MIDI preview latency more tolerable.

Post

Will do. Thanks!

Post Reply

Return to “u-he”