Multi core audio rendering with M1

[helmutson]

I have a macmini M1 , wich checkboxes in the audio settings should I check ?

[Re8et]

Multicore usually is for exporting only. It can make your project stutter in RT. But I never tried an M1 with its icy firestorm cores, so I guess it's up to you to find out!

[buddard]

I have a macmini M1 , wich checkboxes in the audio settings should I check ?

Multi-core rendering enabled, Hyper-threading disabled.
If you're using VSTs, you probably also want to render audio using audio card buffer setting.

[helmutson]

I have a macmini M1 , wich checkboxes in the audio settings should I check ?

Multi-core rendering enabled, Hyper-threading disabled.
If you're using VSTs, you probably also want to render audio using audio card buffer setting.

Nice, exactly like I did. Thank you very much
What do this hyper-theading thing btw ?

[buddard]

Multi-core rendering enabled, Hyper-threading disabled.
If you're using VSTs, you probably also want to render audio using audio card buffer setting.

Nice, exactly like I did. Thank you very much
What do this hyper-theading thing btw ?

Hyper-threading allows multiple processes to run in parallel on a single core. Some CPUs handle it well, others not as much.

[helmutson]

Nice, exactly like I did. Thank you very much
What do this hyper-theading thing btw ?

Hyper-threading allows multiple processes to run in parallel on a single core. Some CPUs handle it well, others not as much.

OK, thanks

[npinero1]

I have a MacBook Pro - M1Pro and I turn off Multi-Core and Hyperthreading. It performs WAY better for me.

[Steedus]

I think I read on another thread here once that audio software largely works 'in series', rather than doing multiple things at once due to the nature of how it needs to process stuff one after the other (makes sense), so Multicore performance would be utilised less, in theory ..

But I was thinking as the base M1 and the M1 Max (in the Mac Studio for eg) essentially have the same single core performance, that an M1 Max would be largely wasted? I think the Max has double the memory bandwidth though so there are other differences, but I just had the thought.. Thinking about my next computer, and I'm so sick of my current 2018 MacBook Pro (6-core intel heat-o-matic) overheating, underclocking, and causing shit performance.

[ScuzzyEye]

These last two replies are really related.

How much multi-core rendering helps depends on if you're projects are tall or wide.

Audio is processed serially in that one effect inserted before another has to finish rendering before the next one can even start. Send effects can't be sent to until everything gathered up. Buses can't start working on summed audio until each channel feeding them is added up. If you're doing a lot of things like that, you might barely be touching the additional cores. The overhead of keeping the cores in sync may even result in lower performance.

But if you have lots of channels that don't really interact until they hit a bus, those can be processed in parallel. The bus is still a waiting point, but the parts that will eventually be summed can be gathered up together.

Lots of independent channels = multi-thread on
A few long chains of interacting channels = multi-thread off

But really try, both. See what works best with how you work.

[EnochLight]

Multicore usually is for exporting only. It can make your project stutter in RT.

What is “RT”? Also, multi-core isn’t just for exporting only. Reason utilizes multi-core very efficiently, actually, and it should never result in stuttering audio. It almost always should be checked “on”.

Perhaps you’re thinking about Hyperthreading?

[joeyluck]

Multicore usually is for exporting only. It can make your project stutter in RT.

What is “RT”? Also, multi-core isn’t just for exporting only. Reason utilizes multi-core very efficiently, actually, and it should never result in stuttering audio. It almost always should be checked “on”.

Perhaps you’re thinking about Hyperthreading?

ReasonTalk? Lol

Or maybe real-time?

[Re8et]

Multicore usually is for exporting only. It can make your project stutter in RT.

What is “RT”? Also, multi-core isn’t just for exporting only. Reason utilizes multi-core very efficiently, actually, and it should never result in stuttering audio. It almost always should be checked “on”.

Perhaps you’re thinking about Hyperthreading?

Ah yes, Hyperthreading, I confused the two. Hyp only on for rendering, but on M1 icy cores it could work differently?? IDK....

[Re8et]

I have a MacBook Pro - M1Pro and I turn off Multi-Core and Hyperthreading. It performs WAY better for me.

Interscting fire and ice... nice! Had you touched the sky yet???

[snapperdub]

No multi-core or hyperthreading ticked for me on my mac mini M1. I was getting too many stutters and clicks.
Much better performance without them.

[EnochLight]

No multi-core or hyperthreading ticked for me on my mac mini M1. I was getting too many stutters and clicks.
Much better performance without them.

Makes sense because M1 doesn’t support Intel’s Hyperthreading, but multicore??? Strange that was causing issues. Maybe it’s an M1/Rosetta thing. When Reason gets native M1 support, I’ll wager it’ll work as intended.

[npinero1]

No multi-core or hyperthreading ticked for me on my mac mini M1. I was getting too many stutters and clicks.
Much better performance without them.

Makes sense because M1 doesn’t support Intel’s Hyperthreading, but multicore??? Strange that was causing issues. Maybe it’s an M1/Rosetta thing. When Reason gets native M1 support, I’ll wager it’ll work as intended.

Hopefully we will find out by end of June? Enochlight? You are a contributor to Reason's great tips. What would you guess the ETA might be for M! support?

[tallguy]

I tried switching on multicore on my M1 and it brought down the DSP meter by 50% Not too shabby. It's worth trying

[npinero1]

I tried switching on multicore on my M1 and it brought down the DSP meter by 50% Not too shabby. It's worth trying

Really?! I had the opposite. That is weird

[npinero1]

I tried switching on multicore on my M1 and it brought down the DSP meter by 50% Not too shabby. It's worth trying

can you take a snapshot of the Audio Preferences page in Reason?
what buffer setting are you using? I am using 128 or 256 and that works great with 30-35 tracks half audio/ half MIDI Virtual instrument tracks.
what Audio Interface? I am wondering if the audio interface or number of Active inputs & outputs make a difference.

[tallguy]

I tried switching on multicore on my M1 and it brought down the DSP meter by 50% Not too shabby. It's worth trying

Really?! I had the opposite. That is weird

I was doing it on a project with only three or four tracks but some very heavy VST effects on them. I suspect you have to try it out on a case by case basis.

[tallguy]

I tried switching on multicore on my M1 and it brought down the DSP meter by 50% Not too shabby. It's worth trying

can you take a snapshot of the Audio Preferences page in Reason?
what buffer setting are you using? I am using 128 or 256 and that works great with 30-35 tracks half audio/ half MIDI Virtual instrument tracks.
what Audio Interface? I am wondering if the audio interface or number of Active inputs & outputs make a difference.

I'm just using my MacBook Pro without my audio interface. I'm looking at 5 tracks, one audio, the other ones MIDI

[stillifegaijin]

I just got up and running on my Mac Studio today and Reason works WAAAY better without multicore or hyperthreading checked. On my previous Intel Mac I used mutlicore but never hyperthreading. When I got setup today I went the same route and all the cores on the Mac Studio were immediately slammed when I opened my session. Playback was awful. I turned off multicore and half the cores dropped to idle while the other half reduced by at least half, most far lower. I was working on a fairly complicated mix, probably 30+ tracks with tons of CPU heavy plugins and weird routing. It was super smooth with neither option checked and I could run the session with a 1024 or even 512 buffer easily. Below 512 it got sketchy. With multicore checked the session skipped and glitched even at 4096.

On my 2010 Intel Mac Pro I ran the session smoothly with a 4096 buffer with multicore checked.

I suspect, and I don't really know shit, that however M1 distributes tasks between its cores is smooth when handled by the system but not handled correctly when Reason tries to "manage" it? I'm not a programmer so I might not be thinking about it correctly. But without multi-core checked multiple cores are still being used but they are used efficiently, not slammed like when the box is checked.

I did time an export though and exporting the song without multi and hyper checked took 3:15 but if I checked them before rendering the export the time dropped to 2:45. So, it export/renders faster but doesn't actually play in real time.

[stillifegaijin]

Oh, after discovering this on my machine I went and tested my wife's M1 iMac. Much less complicated session but same results.

[rootwheel]

Multi-core rendering enabled, Hyper-threading disabled.

Definitely need multi-core normally (although not sure about with Rosetta; that might cause problems). Never really understood why the hyper threading option is still presented even if your CPU doesn't support HT. I've not a CPU which supports HT since the Pentium 4 so have no idea what affect ticking this box would have on performance.

[EnochLight]

Hopefully we will find out by end of June? Enochlight? You are a contributor to Reason's great tips. What would you guess the ETA might be for M! support?

Your guess is as good as mine, I’m afraid. What we *DO* know is that Reason is now at a point, stability and bug-fix-wise, that Reason Studios are now moving focus to core Reason features like VST3 support in Reason standalone DAW, and then native Apple M1 support after that. According to their latest roadmap and interviews, it appears M1 will probably be a summer 2022 thing, but summer goes until September 21, so…