M1 Native Plugin Performance Test vs Rosetta | Using Fab Filter for Apple Silicon in Studio One 5.4

[@thomas-mavian]

Again, nice video Matt! If you engage the *Show Devices" in Studio Ones performance meter and sort the list after CPU usage you can see which plugin eats most cycles.

[@MattHepworth]

Excellent! I'll include that on the last one (assuming there IS a last one).

[@davelongenecker649]

Another great video, Matt! Your tests are very helpful, and you're doing all the tests that I really should be doing, so you're saving me tons of time! And, I'm glad you're testing out Studio One - I really do love Studio One, even with the occasional crashes.

[@MattHepworth]

Dave, thank you! I've actually had Studio One since version 1. I just don't talk about it much! I mostly use the mastering (Project) window for it, though. Lately, a bit of tracking.

[@Soundlagoon]

Hello Matt, may I ask what your conclusion is one year after? I bought just now an M1, because I think for a music notebook it should be sufficient. Would you agree on this? I am a bit shocked by your test.. I also use S1 a lot, but maybe they also managed to improve the DAW for M1 by now? I am hesitating to install Rosetta. There's still plugins and stuff that I miss, but scared that it might cause a performance drop ...

[@MattHepworth]

Great questions! Rosetta works great. I have a video I'm posting in the next couple days that puts a good test on the latest S1 with both M1 mini and M2 Studio Max.

[@brianmartin7710]

thanx for the video. 1 Question. I saw the UAD Console in background. Is it possible to run Studio One M1native with an Apollo Interface?

[@MattHepworth]

Great question! I don't think I've checked that aspect. I'll post back with an answer, though!

[@jorgedejesustejedavaldez5283]

I tried studio one on my m1 MacBook air and Daw crash a lot. also have some weird peaks on the performance meter. In some way, its feel like is not fully optimized yet cause I get the same performance as the last version that runs on rosetta 2.

[@MattHepworth]

Definitely! Thank you for the comment! We're not alone.

[@abj358]

If your Performance meter is always pegged, you may pushing your set up hard continually. I only see this issue, particularly the odd Performance meter bumping that you demoed when using the Intel version, I see this when my M1 mac (or Studio One, not precisely certain which yet) decides that it doesn't want to play nice with one of my peripherals. When I unplug said peripheral, the bumping stops. Of course I need each peripheral I have, so I eventually found that hooking some things up as directly as possible (avoiding hubs while also considering we all have to suffer dock world in M1 land) and use better quality cables, the bumping goes away.

[@MattHepworth]

Thanks for the detailed info! iLok is suspicious to me. I'll check a few disconnects (including the TB hub) and see what I get.

[@doerrjams5770]

I think the CPU metering has to do with the way the new Apple Silicon uses the cores. On an M1, there are 8 cores: 4 high-performance cores and 4 high-efficiency cores. It seems that DAWs and other apps are still figuring out how to best optimize use of these cores as well as how to meter them. In Logic, if I open up the CPU meter, at first there are only two CPU meters and they max out quickly. Then in Logic's prefs, I can choose to use all 8 cores. The processing starts to spread out over the 8 cores, but mostly operates in the high performance cores. Also, sometimes it seems like a couple of core meters will be maxed and the others are being under utilized. All this in Logic, which is designed by the same company that's making the M1 chip. So, it seems pretty clear that it will take other DAWs time to figure out how to optimize use of the M1 architecture as well as properly reflect it with CPU meters.

[@MattHepworth]

This is very possible, but I've also confirmed that once I exceed 50% CPU I get spikes while screen recording that stopping screen recording immediately fixes. Could even be a combination of both.

[@teddym2808]

The issue is that dropout protection (hybrid buffer) of S1 is completely, 100% broken. You have record armed tracks, where DP actually becomes dropout *maker*. I have a topic going on about it at PreSonus forums currently, the issue was discovered in 2019 by someone else who was ignored, now I am being ignored or people just don't get it nor want to get it. Plus, you are using 16 buffer. 16 buffer plus DP is basically a disaster recipe. What I would do is set to 64 buffer, which is still plenty fast with Quantum, and disable DP entirely. Remember, the tracks that are record armed ARE on 16 buffer anyway, but S1 has an issue negotiating between the DP playback buffer (in your case minimum or 128 samples) and the low record buffer. PT, Logic and Cubase on the other hand, which use identical systems, work flawlessly in this regard. As long as the dropout protection buffer size is higher than the main buffer size in audio settings, it will cause the problem you see here, and make low latency monitoring and recording in S1 all but impossible for mor than a track at a time. The other thing is, if you disabled DP entirely, even at 16 buffer, with those few plugins you had, it probably would have been OK. The issue is DP. It really sucks. I was at 32 buffer on PT before on a 12 core M2, PT doesn't support 16, and remember PT will only use the 8 P cores of the M2, and I had 16 UAD opal synthesisers armed in record mode and I was playing away at the KB and it performed exactly as expected. Basically showed about 25% usage on each core. LOL. Kind of blew me away TBH. S1 performance has always been really bad on Mac, and I am sad to say it's the same in 2024. BTW, this is why I still rely on DSP, even with computers being as powerful as they are today. DSP for record monitoring external signals is 100% reliable every single time and leaves the CPU for native FX and instruments in mixdown. PS the Windows version of S1 is broken too. V6.52 last tested.

[@MattHepworth]

@teddym2808 thanks for the detailed reply! Unfortunately, 16 buffer is the only way to be below 2ms RTL at 44.1kHz. At 48kHz you can use a buffer of 32, but that'll only be under 2ms if the plugins don't add any latency. 64 buffer is definitely a 100% non-starter for those that are sensitive to latency (including me). The latency is just way too high to reduce the comb filtering phenomenon. Sub 2ms RTL is a requirement to rectify that. It's really interesting that dropout protection actually causes spikes and hinders low latency performance. I have a LITTLE bit of pull with some people at PreSonus. Let me test this and see about putting it on their radar.

[@teddym2808]

@@MattHepworth Oh wow, OK, you need 2ms or under.. That's fast! I am happy with my 2.2ms with UAD and even up to 4 with some of the plugins. 5 or under total RTL is always my goal.

[@MattHepworth]

For a lot of things 5ms is totally reasonable, but not for vocals or some acoustic instruments/horns, etc. for people extra sensitive to the comb filtering.

[@weiusi]

i know this is nothing related but how did you separate the m1 native icon from the rosetta one which allowed you to have both in dock

[@MattHepworth]

Great question! I have a co-install of 5.3 and 5.4. In the apps folder I just renamed the original file before installing 5.4. Hope that makes sense.

[@weiusi]

@@MattHepworth that makes a lot of sense thanks Matt

[@MattHepworth]

Glad to help!

[@TheRobGuard]

So what does this test say? That using Rosetta is better? Could you compare with using a 2020 mac mini using an i7 cpu?

[@MattHepworth]

That's a great idea! I'll either re-upload this video with that attached, or do a cleaner video that compares all three.

[@skk6811]

This DAW is my favorite but crashes a lot. Time to go back to Logic pro.

[@MattHepworth]

Stability is the most important part.

[@blazikin89]

32 sample buffer at 44.1kHz is less than 1ms of buffer delay, and your plugins are adding 15ms already lol

[@MattHepworth]

This is very interface dependent. Quantum has the lowest latency of any interface. It's around 2ms for 32 buffer at 44.1. 1.22ms at 16 buffer. I select plugins that add zero latency. Did you see something different in the vid? Would you post the timestamp?

[@blazikin89]

@@MattHepworth I haven't used this DAW so I may be misinterpreting - the bottom left under your sample rate says 15ms throughout the video. Besides that, in your latency settings, the input latency and output latency are the same for both buffer sizes. These are just 24 samples / ( 44100 samples / second ) = 0.54 ms, and same calculation for 32 samples gives 0.72 ms. If your interface has a "realtime monitoring" feature I would highly recommend using this during live tracking instead of pushing to tiny buffer sizes, which can cause inexplicable recording glitches that are subtle enough to hide until you're already mixing.

[@MattHepworth]

@@blazikin89 I see where you're coming from. Studio One offers a "Green Z" latency option. Using that, like in this video, any record enabled track has latency equal to only input and output buffers, plus the AD and DA latencies, while playback tracks are at the higher buffer. In this case, Green Z is 1.27ms RTL at 16 buffer and 1.99ms RTL at 32 buffer (40 samples input plus 48 samples output). Zero added plugin latency. The Quantum is a native-only interface, but is capable of the lowest possible native latency because of that. I'm an advocate of DSP for exactly the reasons you describe above, but my experience with Quantum, overall, has been very positive when used with Studio One with Green Z.

[@blazikin89]

@@MattHepworth I haven't used any of those tools so thanks for the exposé. Guess I'm not very worried about those levels of latency in my work. Playing guitar thru an amp 10 feet away is already 10 ms of RTL :)

[@MattHepworth]

This is true, and sub 2ms is really only critical for vocalists - especially those that are sensitive to that comb filtering. Electric guitar is usually just fine with 10ms. Thanks for the comments!

[@Harrysound]

16 samples is insane

[@MattHepworth]

Goal is to stay under 2ms to minimize the comb filtering phenomenon on vocals, etc.. 16 samples is great for that. At 48kHz you can also use 32 samples to be at 2ms RTL, but that's before plugin-induced latency.

[@fidandbooze]

Dude, I’m working with 512-1024 samples since over 20 years 🙈 comp filtering LOL

[@MattHepworth]

@@fidandbooze Are you using DSP for input monitoring? On DSP enabled systems (RME, Apollo, HDX) I'm usually at 1024 buffer, too. For native to have latency similar to that you pretty much need to be 16 or 32 (max).