DAW benchmarks on new Mac M4 chip

[Freaqpeak]

delete

[PAK]

That video didn't use the standardized DAWbench-tests so it is impossible to compare results to anything that wasn't included in the test (AMD/Intel or ARM for Windows) .
EDIT: Seems like SGA1566 isn't available for Apple Silicon so the previous DAWbench isn't possible to do...

Yep. Ironically, the first thing the download page for 1566 says is its successor has a ”~20x increase in performance.. “ So not just an older plugin, but one which has since had huge performance improvements!

Likewise, the last Reaplugs FX Bundle on the Cockos website is from 2016, and the default DAWBench download only includes x32/64 versions. Maybe there’s an Apple Silicon version elsewhere? Otherwise that means the internal Reaper Compressor? So you're left with a Kontakt 6 Polyphony test. Even if you could get everything running, it all communicates much less than you’d probably want..

BTW Reaper is willing to load up CPU cores to the point of an unresponsive GUI. Whereas other hosts often keep some resources in reserve so their interface is always responsive. The result is Reaper will usually come out ahead in host benchmarks..

[machinesworking]

The instances where you need Thunderbolt for audio production are very few however. A stream of 192 KHz/24-bit audio is just under 5 Mb/s, meaning even USB 2.0 can support 96 channels of 192 KHz/24-bit audio.

This is maybe an unintentional straw man, but it's a straw man. Most everyone will end up using external SSDs at some point who uses sample libraries, and load times for those libraries can be drastically cut down by fast protocols like USB4 and TB5. Load times in general, then there's scoring to film, etc. etc.

[machinesworking]

BTW Reaper is willing to load up CPU cores to the point of an unresponsive GUI. Whereas other hosts often keep some resources in reserve so their interface is always responsive. The result is Reaper will usually come out ahead in host benchmarks..

More to it than that, but the main point I would make here is a standardized test for performance in a DAW is a "to failure" test with a plugin like Diva. With that type of test Reaper and DP are head to head the best at it here (I don't own Cubase or Studio One). DAWs like Live and Bitwig have always prioritized uninterrupted audio, i.e. less or no glitches when adding a heavy plugin while the song is playing etc. what this means is they do not use a secondary buffer like Reaper, DP, Cubase, Studio One etc. do, so tracks are not really affected by whether or they're in record mode, whereas Reaper, DP etc. are heavily affected by the status of the record button since it takes it out of this larger buffer or pre rendered state.

With Apple Silicon and the other chip makers starting to use Performance and Efficiency cores another thing separates out DAWs, some do not use Efficiency cores at all, here it's Bitwig, Live and Logic, none of them show any significant use of e cores when the p cores are maxed out and audio is crumbling. With Reaper and DP you get maxed out cores across both p and e.

I have the 24 core M2 Ultra here, there's not any reason to use all 8 e cores for the GUI, and the difference in track count is insane, well below any significant GUI sluggishness.

[jamcat]

Studio One users: Upvote this feature request to fix efficiency core use:
https://feedback-software.presonus.com/feedback/186615

[PAK]

More to it than that

Yes. Obviously being able to use cores, along with latency and buffering, are bigger factors. I should've added "other things being equal". There’s maybe a bit less awareness that hosts, like Cubase or Protools, keep some resources in reserve to allow their GUI to stay responsive..

A standardized test for performance in a DAW is a "to failure" test with a plugin like Diva. With that type of test Reaper and DP are head to head the best at it here (I don't own Cubase or Studio One)

Diva does make a very good test due to the different quality modes and its ability to switch between single and multi-core. Of course, that assumes a sufficiently CPU heavy patch is used for testing too, plus an awareness that multi-core costs ~30% performance, so should only be used to fill efficiency cores or any spare capacity in a single core (Since Apple Silicon single core is getting fast enough that 16 note Divine likely won’t be maxing a core out.. )

whereas Reaper, DP etc. are heavily affected by the status of the record button since it takes it out of this larger buffer or pre rendered state.

Cubase is the same (real-time for record enabled, ASIO Guard to increase buffers otherwise). However, the difference is definitely reduced for heavy single core tasks. EG Diva will manage 12 note Divine (single core) on M1, whether you use ASIO Guard or not.. though it can *almost* manage 16 notes with AG

It’s also quite predictable, which is good for benchmarks. IE Just multiply by the amount of performance cores, and you can predict the amount of instances at "x" polyphony. Bit less clear when multi-core would need to be used to fill efficiency cores or spare performance core capacity, but I'd still say a lot more real-world useful than most tests out there..

[jonljacobi]

Studio One users: Upvote this feature request to fix efficiency core use:
https://feedback-software.presonus.com/feedback/186615

I'm not exactly sure I'd consider this a "fix". I'd certainly like the option, but the basic programming credo for these things (and threading) is to utilize performance cores for the heavy lifting, while leaving efficiency cores (or a thread for two) for other system tasks.

That said, leaving one or two available would seem adequate. Ideally, you could choose the number and type of cores to utilize.

[jonljacobi]

Got to mess around more with the Macbook Pro M4 Pro. It's a very, very smooth computing experience. I didn't think I'd notice a difference from my M1 Max, but I did. It's certainly not like going from HDDs to SSDs, but it's palpable.

[machinesworking]

Studio One users: Upvote this feature request to fix efficiency core use:
https://feedback-software.presonus.com/feedback/186615

I'm not exactly sure I'd consider this a "fix". I'd certainly like the option, but the basic programming credo for these things (and threading) is to utilize performance cores for the heavy lifting, while leaving efficiency cores (or a thread for two) for other system tasks.

That said, leaving one or two available would seem adequate. Ideally, you could choose the number and type of cores to utilize.

Until recently you could access a simple to failure test using Diva on a Logic Pro fan page, using this as a base (same MIDI, settings and preset), I've noted the predictable: Live and Bitwig do not use e cores, and surprising: Logic (and apparently Studio One) also does not use them.

DP and Reaper use them and get a massive boost from doing so. On a Mac Studio Ultra 16p and 8e core machine, roughly Bitwig and Live get around 80-90 plugins, Logic gets 105. Reaper and DP get 140. Between a secondary buffer and using e cores DP/Reaper (and apparently Cubase), get roughly 45% more CPU usage than Live or Bitiwig and 25% more than Logic.

We're not hearing widespread reports of Reaper, DP, Cubase being less stable than the DAWs that do not use e cores, so in practice it's seeming like it's not a good idea to ignore them. Apple just came out with chips that use 6 e cores to 4 p cores, so that's a massive boost in performance for chips like that to be able to use them.

I would imagine in all respects the e cores are about as powerful as a top end core from 8 years ago, hardly anything to waste.