Menu
What's new
By:
Filters

The Perfect DAW in MacOS

OK because these kinds of tests can vary by a bit I retested with multi core off and then with it on.
Like I predicted no one did that well with multi core on, but, and this is to Blue Cats issue, none had dropouts before failure, it wasn't like multicore alone caused issues with low CPU demand, just that on fast modern machines, it's actually a negative. You're not going to tap out a single CPU with a plugin on an M2 Mac or i9 Intel beast, so letting the DAW and OS handle CPU allotment is going to produce better results.

48khz, 128 buffer, the Diva test mentioned above. Sonoma 14.2.1 Mac Studio Ultra 16 P, 8 e cores 128GB RAM, 4TB SSD, Babyface FS. No real precautions, Safari open, Activity Monitor open etc.

Reaper gets 37 tracks with multi core on, 140 with it off.

DP11 gets 38 on 140 off.

Logic Pro gets 14 on and 107 off.

With multicore off in Diva, both Reaper and DP11 are pegging all 24 cores, using about 2000-2100% CPU. Logic pegs all 16 Performance Cores and uses not surprisingly, 1600-1650% CPU.

DP11 is using around 1850% CPU in Multicore mode, for a mere 38 tracks. All 24 cores are pegged. So multicore messes with CPU performance. This again isn't anything new. Intel Mac users will likely get similar results.

It's interesting that Logic apparently is the DAW that Urs was surreptitiously mentioning by saying that some DAWs responded badly to multi core on? I'd Love to see how Cubase and Studio One did in this, but I don't own those DAWs. The rest (Reason, Bitwig, Live etc.) would do worse for sure. Being a DP user, it's pretty cool to see it over the year really improve it's CPU management, reaper until Apple Silicon, always eked out a few more tracks than DP or Logic.
 
Last edited:
Dewdman42 said:
Would be nice if in logicpro we had some option to force more ecore use in case we are simple cases like yours where it would be fine
Click to expand...
I'm new to using ARM Macs, so I'm curious about what you wrote above. I've just learned that it's already possible to tell Logic to use either no efficiency cores, two efficiency cores or four...

performance vs efficiency cores Logic.png

...but according to those I've been on contact with about this, it's usually best to use Automatic mode – or to manually set Logic to use only performance cores and no efficiency cores at all. If the automatic mode is as intelligent as some claim it is, which other settings do you think would be good other than those who already exist?
 
I agree with you. The word on the street from people doing testing is that they have not been able to find a way to force LogicPro to use efficiency cores, so they go unused and so far in some tests causing LogicPro to benchmark with less tracks then can be done with other DAW's such as Dp, Reaper, cubase

Notice the above says automatic, or else you can set a decreasing number of performance cores...but there is nothing in that menu to say anything either way about efficiency cores.. And basically people are finding in tests, that the efficiency cores are being entirely ignored by LogicPro 10.8

my suggestion would be more configuration possibilities to let us force LogicPro to also use efficiency cores if we want, or perhaps some variation in that as well to fine tune how much it uses efficiency cores, maybe a seperate menu for efficiency cores where automatic means 0 and then we can change to to as many or view of them as we feel like using. This may or may not result in dropped audio in some cases, but in many cases it might not, so we ought to be able to force it and see if i can get more out of our machine if we want to.
 
Dewdman42 said:
you can set a decreasing number of performance cores...but there is no thing in that menu to say anything either way about efficiency cores
Click to expand...
The way I have been explained this, is that if you select eg. "14 (12 High Performance Cores)", this means that Logic is now using 12 performance cores (the maximum on my system) and 2 efficiency cores... since, after all, 14-12=2. :)

Likewise, if one selects "12 (12 High Performance Cores", this is a message to Logic about not using any Efficiency cores at all. And "16 (12 High Performance Cores) gives Logic access to use all the efficiency cores as well (not recommended). I guess the only reason for not mentioning efficiency cores in that menu is to avoid really long text entries in these popups menus.
 
Last edited:
I don't have an AS Mac to test. you tell me if it does that. People that have been reporting on it say it doesn't do that. maybe its just a simple bug...fix that and then it would be able to do as I suggested perhaps, or maybe there is a way to get all the e cores too.

By the way that feature used to be called "threads" not cores...and I am somewhat skeptical that the internals actually are determining anything about which or how many cores to use...it just got labled that wya here for some reason...but anyway, benchmarks are reporting that e cores aren't getting used even with the 14 and 16 setting you mentioned
 
Dewdman42 said:
why would you use use less performance cores in order to use a couple e cores?
Click to expand...
First, I agree with you wrote earlier about this whole scenario is work-in-progress. And I can't see why someone would want to use fewer performance cores – except scenarios where several other apps which are open at the same time also may need to use the performance cores – like eg. VePro.

Btw, I don't know if Sine or the Spitfire/Synchron players need their own way to lock performance cores to themselves, and I know close to nothing about video editing, but I guess the solution Logic has now may be a good idea in some scenarios now or in the future. I don't see why they would have implemented such a menu if it has no real life benefits at all.

Also, Apple's operating system, Spotlight, various current and future widgets, AltiVerb, hardware mixer automation systems controlled by software in the MacOs, maybe having Dorico or some other app open at the same time... standalone synths, a background audio or video meeting and so on: there are many situations which potentially could raise the need for allowing non-Logic-Pro operations to reserve a core to two. And if they all claim as many cores as their desire, it seems like a better idea to me to offer both automatic and manual control of the whole core scenario than not doing it.
 
Last edited:
yea I do think its a work in progress, so I'm not too worried about it, I'm not on apple silicon yet either so it doesn't even affect me and by the time it does I think Apple, Steinberg, VSL, MOTU and the rest will all sort out best practices for dealign with these two core types.

That feature used to be called "threads" not cores and it was a way to configure how many threads that LogicPro uses. Normally its the OS itself that would determine how to share threads between all the cores, based on the number of threads, and timesharing with other processes also. So anyway, normally you would leave it up to LogicPro with Automatic thread count, but if you wanted to, you could theoretically reduce the number of threads, knowing that VePro is also trying to use a bunch of threads and hit all the cores, etc..

With the new architecture I gather that the OS core schedule is much more complicated due to the nature of e cores and p cores, etc..and I don't really know all the details of that...but this preference to me just looks like it always did, specify the number of threads...and someone presumed that somehow that would add a couple e cores or something if you assign more threads...something like that.

But anyway, nobody really "locks" cores to themselves. It just doesn't work that way. There are complicated multi-threading schemes that has different threads from different processes share use of all the cores. At any given moment you have many threads happening between all your programs, they are all sharing time with the CPU, including to the different cores. You might have 100 threads all happening at once between all your software...they're all taking turns with the CPU cores. Managed by the OS.

What programs can do is manage threads, the way they wait on each other, the way they are prioritized, etc...and one program really doesn't have the power to hog the cpu from other programs and lock it down. If your program uses more threads though...then it could swamp the cores and give other programs with just one or a few threads harder time getting to it. etc. its complicated even with single core type. With the new architecture its even more complicated because Apple is trying to get long battery life and lower operating temps by using e cores and trying to figure out which tasks should go to p cores and which can be done on e cores.etc...
 
  • Like
Reactions: Vik
Dewdman42 said:
But anyway, nobody really "locks" cores to themselves.
Click to expand...
Sure, if they all did that without any way for the OS to override it, there would probably be crashes and other horror all the time.

I guess Apple's ideal situation would be if all relevant apps had the same options as Logic has, and on top of that, they also do allow, to some degree, users to choose settings that are not recommended … combined with recommending us to stay with either Automatic or to grab only performance cores, but no efficiency cores. And there's probably also a lot more WIP than this, for instance possible work on ways to use the power in the GPU cores for non-graphical stuff.
 
My thoughts are that right now Apple is just taking an overly conservative approach to handling DSP with e cores..nothing else. But I feel some of the other DAW's are probably taking an overly liberal approach. But on the other hand their liberal approach appears to be working fine for some people according to them, so probably the true place to be is somewhere in the middle. They came out with some some updates to CoreAudio which is supposed to provide more ability to handle the cores in some way, which unfortunately is very difficult for VST hosts to make use of. However, at the same time, we can say that logicPro is currently underperforming those other hosts...so probably Apple took an overly conservative approach. After a year of complaints from LogicPro users they will probably design things a little better to make better use of the e cores then is currently the case.

Meanwhile Steinberg and others have to figure out how to navigate the dual core type architecture outside of CoreAudio...

so things will be changing and developing. I do think there is something to be said on both sides, Apple is pretty smart, I think they have done what they have done for valid reasons and perhaps the other DAW's which are taking a more liberal use of e cores may end up having to dial it back in some way at some point. There are all kinds of reports ranging from some people saying they have no problem at all using all the e cores so everyone should shut up and do what Steinberg is doing....to the other end of the spectrum with random use cases where get unexplainable audio drop outs etc. Possibly rarely? I don't know...but anyway, think the truth is somewhere in the middle. These two core types do need to be handled specially, and probably its more complicated and probably it needs to be made available to non AU DAW apps in some way....and at the same time, Apple probably took too conservative of an approach with LogicPro for now... I think users will generally prefer what DP, Cubase, Reaper are doing..use all the cores...even if once in a while they run into some strange unexplainable drop out or something. LogicPro used to be one of the most efficient DAW's but it will lose that credibility quickly if the others handle so many more plugins and usually without a problem. The truth is in the middle I feel...and all these various parties have to figure out how to deal with it.
 
  • Like
Reactions: Vik
Vik said:
I'm new to using ARM Macs, so I'm curious about what you wrote above. I've just learned that it's already possible to tell Logic to use either no efficiency cores, two efficiency cores or four...

performance vs efficiency cores Logic.png

...but according to those I've been on contact with about this, it's usually best to use Automatic mode – or to manually set Logic to use only performance cores and no efficiency cores at all. If the automatic mode is as intelligent as some claim it is, which other settings do you think would be good other than those who already exist?
Click to expand...
So all you need to do to prove that this isn't a thing at all, that Logic is not acknowledging Efficiency cores at all, is to run the tests I did above. Inside Logic it will look like it's using Efficiency cores, but it flatly is not. Just open Activity Monitor (search Spotlight for Activity Monitor.app) and see for yourself. the fact that Logic can see the Efficiency cores and does not use them is just probably an artifact in code left over from before Efficiency cores were a thing.

As posted above, I've got Logic here, and an M2 Mac Studio 24 core. it uses effieincy cores only for likely OS related things when using Logic Pro.
 
Vik said:
Sure, if they all did that without any way for the OS to override it, there would probably be crashes and other horror all the time.

I guess Apple's ideal situation would be if all relevant apps had the same options as Logic has, and on top of that, they also do allow, to some degree, users to choose settings that are not recommended … combined with recommending us to stay with either Automatic or to grab only performance cores, but no efficiency cores. And there's probably also a lot more WIP than this, for instance possible work on ways to use the power in the GPU cores for non-graphical stuff.
Click to expand...
Some of the weirdness of this can't be denied. Blue Cat mention their issues with multicore plugins in their line up on Apple Silicon in what they believe to be the fault of E to P transfers or lack of, is tied to the VSTs, AU spec has task handling etc. that's specific to AU, i.e. in some way Logic shouldn't be as affected by the dropouts Blue Cat are experiencing in that case. The fact that at the level of Settings in Logic it still looks like you can choose all 24 cores, and the CPU meter still claims they're being used, but clearly in Activity Monitor they're not being used at all... So something is likely to change in Logic code soon, either they show in the Settings and manual to only use P cores etc. or they fix something internally that's messing with Logics ability to use E cores. My guess is the latter, because the main issue that can be tied to E cores is multicore VST3 plugins experiencing dropouts in low CPU using scenarios as referenced by Blue CAt.
 
machinesworking said:
So all you need to do to prove that this isn't a thing at all, that Logic is not acknowledging Efficiency cores at all, is to run the tests I did above. Inside Logic it will look like it's using Efficiency cores, but it flatly is not. Just open Activity Monitor (search Spotlight for Activity Monitor.app) and see for yourself. the fact that Logic can see the Efficiency cores and does not use them is just probably an artifact in code left over from before Efficiency cores were a thing.

As posted above, I've got Logic here, and an M2 Mac Studio 24 core. it uses effieincy cores only for likely OS related things when using Logic Pro.
Click to expand...
Hi, I'm not trying to prove that this isn't a thing – I've had an ARM Mac for a week and simply don't know what I'm talking about. Like Dewdman wrote, maybe Apple is very conservative in terms of allowing Logic access to the E-cores, and that things will change.
 
Vik said:
Hi, I'm not trying to prove that this isn't a thing – I've had an ARM Mac for a week and simply don't know what I'm talking about. Like Dewdman wrote, maybe Apple is very conservative in terms of allowing Logic access to the E-cores, and that things will change.
Click to expand...
That's perfectly fine, I wasn't attempting to argue about it, you just asked a bunch of questions about E cores and Logic, I just did some tests on Logic with E cores, and yeah it's likely the Logic team release a version that does use the cores, or there's some reason given that I haven't run into. With these machines it's not the end of the world for sure, we're talking 107 instances of Diva here, a CPU hungry plugin. People have used Live for decades now and it's always performed much much worse on these tests.
 
I'm a Digital Performer user and that DAW really resonates with me. Doesn't get nearly the respect it deserves, but I don't really fret about that. I just get my work done.

That said, I've always felt the best DAW is the one you work fastest in, either because you've put in the time to TRULY know it... or it just clicks with the way you think.

There was only one DAW that came close to tempting me away from Digital Performer many years ago. Am I the only one who dreams wistfully of what might be today had Opcode not been absorbed by Gibson and Studio Vision Pro had continued being developed all these years? ;)
 
either because you've put in the time to TRULY know it... or it just clicks with the way you think
Click to expand...
Exactly right - I recently made a switch, no reason to mention the programs. The one I left was very very good, and perhaps its top version is better than the one I'm now using - but the one I'm using is perfectly situated for both personal workflow, the type of music I write, and its adaptability to my particular music libraries. Interestingly, both have the same principal digital architects and are similarly constructed.
 
I don't think there is an absolute best DAW.

I have some small needs (typically a basic MIDI recoder + VST host + adding a backing track). And I find Reaper to best fit my needs. On the pro side :
- better Band in a Box integration (the BiaB VST has an efficient Send to Reaper button)
- ability to map a key of my piano to a Reaper function (C1 is mapped to Start/Stop, usefull with a BiaB arrangement)
- just clicking on the audio interface info : [48kHz 24 bits WAV ....ASIO] opens the audio setting dialog and releases the audio interface which is available for other apps. (Note recent Cubase versions have a setting were the audio interface is released when Cubase is in background).

The retrospective recording of Cubase could be nice for my needs...

But lets suppose I want to control an external synthesizer. Here, Cubase and its instrument (program) drop down menu has no match from other concurrent DAW. (Cakewalk .ins file format is a mess... no synthesizers have a bank division which match instrument categories... a pity that Reaper has invented a .reabank file and hasn't fixed it)

Lets suppose I want to mix audio parts, the channel strip of Cubase would be appreciated.
 
Last edited:
You must log in or register to reply here.
Top Bottom