Macbook Air M2 and DP 11 Disappointing Performance

[chokobo99]

A couple things, first off are all your plug ins running natively or in Rosetta?

I 100% have the opposite experience, the M1 Air here has been great. I clocked some ridiculous amount of instances of Diva on it when I firs got it etc. There is not a single logical reason you're having this issue, it's not the M2, it's something else, period, there's not a single thing that the 2015 should compete with the M2 in.

It doesn't seem to be related to Rosetta in any way whatsoever, and yes it is an M2 issue. The M1 is different enough that it's a false trail to use it as evidence that it's not an M2 issue. DP on an M2 portable can easily go into this state.

[chokobo99]

There's too much that we don't know.

Are you using any VIs? If so, are you running them in one instance of a player or is each running in its own instance? Except for some VIs designed for multi-core performance, the OS (Mac and Win) assigns each instance to a core. This has been true going back 25 years or more.

I don't use our M1 MB Air for DP but I do test it now and then. I haven't been able to break it.

I've been doing a lot of testing in this area. It's not specific to any one plugin. Many plugins can trigger it. It's not related to Intel, which precludes the other OS, and you wont see this issue on an M1. I don't have access to an M2 Studio, so I don't currently know if it extends past DP on an M2 portable. But you wont see it on your M1 machines.

[chokobo99]

The issue that is most problematic with the Apple Silicon machines is Single Thread performance. Although the AS SOC is amazing, it isn't extremely difficult to overload a single CPU core with low buffer and complex live signal path. And, IIRC, Live Performance Mode only hurts in that this mode disables DP's pre-rendering.

Not sure why you need to run in Live Mode; perhaps you can explain your setup and requirements in a bit more detail.

Based on some tests I've seen, 128 appears to be the buffer sweet spot for Apple Silicon. I find 128 is plenty responsive for me when using VIs, but I'm not trying to play audio thru DP in real time as I monitor analog sources via hardware while recording.

Amazing or not they can still have issues, and DP 11 with Ventura on an M2 portable can have serious performance issues. I have been able to trigger this state with two plugins, on one track, and the rest of the session empty. Nothing playing, just using the synth plugin going through an effect, and DP will run out of CPU.

These don't seem to be related to buffer size, as it can happen with all of the available buffer sizes within DP.

Are you running on an M2? If not then you likely wont see this issue. I haven't seen this happen on the M1, so it's not likely to be a proper platform on which to test for this issue. Certainly it's possible, but to do initial investigations the M2 is the proper machine on which to test.

[chokobo99]

Have you updated to DP 11.22? If not, do so. Are you running the latest versions of your plug-ins and VIs?

Then there's this:

you could reach out to MOTU support and see if there are some settings you could try to improve your performance- or at least to let them know that the performance you're seeing isn't proportional to the monster machine you're running.

This does occur with DP11.22, under 13.5 of Ventura.

MOTU tech support is fixated on testing this on Intel machines on the other OS, so they currently haven't experienced the issue. It seems very specific to M2 machines. It could be related to Ventura, but it's likely DP on M2 machines. So far I've not been able to test it on an M2 Mac Studio, and it doesn't happen with Logic or Reaper on the M2 MBP.

[chokobo99]

Last word from me on this.

I just moved the project back to my 2015 11" (!!!) MBA 2 core 2.6 i7 (I love it because it' so tiny.) At a 64 buffer, processor idle is about 40, and 90ish when a track is running (with the odd red peak.) I'l prolly just keep it at 128 for gigs.

I'm an IT admin, database programmer, a synth programmer since the 80s, and performing musician, and have been running live tracks in DP since version 7.

As far as user error, when I got the M2, all I did was buy and install DP 11, D/L all the newest installers for the Waves, Roland and Korg stuff, plugged in my (class compliant) USB 2x2, and load the chunks from the old project. And waited for DP to analyze the chunks...

I just can't imagine being so incompetent that I can somehow make a project that runs fine on my 8 year old laptop max out DP's audio engine on a brand new computer. Unless the software and hardware are not talking to each other...

The M2 is hard limiting DP's processor access to 15% of the M2's processing power, according to Activity Monitor.) I had NOTHING to do with that.

As I said previously it's not you, it's DP on the M2. Don't let foro people get you down with their adhoms, it's not worth it. You posted for help, and if you aren't getting it from certain individuals just ignore them.

[chokobo99]

...It would have been interesting to try to re-create the project in another DAW, like Logic perhaps, and see if you noticed a big difference. Might be there's some quirk with the M2 that DP doesn't like? Sorry it didn't work out. Perhaps something is going on with DP and M2 processors? I'm having a pretty decent experience with the M1 Max in my Mac Studio.

Where in Hawaii? I grew up on Oahu. Dad currently lives on Maui.

I've done similar tests in Logic and Reaper, and they are not exhibiting these issues. Unfortunately, as I stated previously, I don't have access to an M2 Studio running DP so I haven't been able to extend the testing into that realm, but on an M2 MBP running the current version of DP (11.22), and the current version of Ventura (13.5), it is very easy to trigger this issue.

[chokobo99]

Again, regardless of MOTU tech supports suggestion, Live Performance mode literally is set up to use more CPU power not less. Like more than one person has mentioned, if you see 80-90% in DP and 15% in Activity Monitor then it's blatantly obvious that you're loading a single track with heavy plugins and expecting the results to be different. The difference in machines is 8 cores VS 2 but the way DP performance meter works it will tell you the highest cores rating, not a culmination of all cores. So IMO you returned the device because you saw a "potential" issue.

In any multi core machine it's best to recognize the limits of loading one track VS multiple tracks. I'm certain that you would get far more performance out of the M2, but again, on any machine you can overload a single core by overloading a single track in a DAW.

Why am I certain of this? because you're using it for live performance, i.e. record arming tracks, which loads more CPU on a single core. I'm a bit of a geek about this stuff and spent some hours going over how DP and various other DAWs react to track loading, arming and CPU. Plus, there really isn't a single DAW that doesn't over react to CPU loading on a single core, since it's possible to glitch audio even on a 28 core Intel or 24 core M2 doing so.

Plus, this is the first reply where you're now claiming that the M2 was maxed out compared to your older laptops. Again, you obviously didn't want help, you wanted to complain about a problem you perceived, that frankly I don't think really existed in the first place. Never trust a performance meter in a DAW as being all that's left for that DAW, think of it as all that's left for that track. That's all.

Would you say it is reasonable to expect that only one low cpu intensive synth plugin, and one Eventide floor pedal reverb plugin on one channel in the entire session shouldn't overload the performance meter? Because that's all it takes to see this happen within DP on an M2.

[chokobo99]

AFTER ALL OF THIS DISCUSSION, what I could have done is try using multiple v-racks to see if each V-Rack would would access a different core in the M2 processor. Can someone please try that and report back?

While I haven't tested any of the v-racks (I don't use them—personal preference) I have tested a wide selection of 3rd party plugins, and it doesn't seem to be a function of the plugin per se, as pretty much any combination can get this to trigger.

[chokobo99]

Of course I misspoke, it was 2010 ish, and that article I now remember was actually posted on MOTUs web site. Please forgive an old guy who has used computers in music since almost day one (Atari ST) who can't keep track of the passing decades.

BTW, the "Puff" resume was a specific response to a previous post concerning my competence. However I did relate to your anecdote. I have found that musicians are able to use their creativity to work out solutions to (and have the drive to want to solve) problems that civilians cannot.

Peter

Peter, when they come at you like that ignore them. It's not even worth your time to respond to such posts.

[chokobo99]

My buddy who is an Apple developer and tour level computer music tech has just replied to an email.

He tells me that you should NEVER run VIs directly inside DP, precisely because you cannot control core/thread usage. The correct method is to use a Vrack for real time audio processing, but to use Main Stage to host all VIs. The reason is that MainStage lets you explicitly define Core usage (which totally makes sense as it's an Apple product.)

https://support.apple.com/en-in/guide/m ... 9453e0/mac

And NEVER use Roland Plugs in a pro situation, they are horribly written (but that's his story, not mine, so please don't comment on it. His buddy used to code for Roland tho...)

For me, this is the correct/final answer to my initial question. Thanks to everyone for their input.

Peter

That's a very interesting post! He's basically stating to not use DP for soft synths, which in many cases would render it obsolete. I'd like to know more about what his reasoning is with the Roland soft synths.

[chokobo99]

Auxes are not pre rendered, essentially if anyone else is running into live performance issues and track stacking, it's best to use the Activity monitor in multi core CPU mode to see where cores are distributing CPU. Couple that with the Effect Performance Window in DP and you can narrow down any issues.

Again, I'm certain almost nothing in this thread relating to "teething" issues with Apple Silicon has any merit, it's just unfamiliarity with DP11, and a lack of patience. there's just a handful of actively supported plug ins at this point that haven't made it to Apple Silicon, and without any hyperbole, it's just miles and miles better.

Having done this, it would seem that DP is struggling to work with the M2. It doesn't matter which plugin is employed, this performance issue can still be triggered on the M2—even if it is miles and miles better, the performance it currently produces on an M2 is quite low, and not even as good as DP on an Intel Mac.

[chokobo99]

I realize that the OP has returned the Mac. I'm sure someone is getting a very nice refurb model in return. There were two questions about “Rosetta” that were never answered-just a lot of “Auld Lang Syne”. This is fine, but please understand that 25 years of MacOS has passed you by.

From my tests Rosetta is not a function in this issue.

[chokobo99]

... if anyone else is running into live performance issues and track stacking, it's best to use the Activity monitor in multi core CPU mode to see where cores are distributing CPU. Couple that with the Effect Performance Window in DP and you can narrow down any issues.

Interesting topic. Perhaps one can ask, after decades of advances in computing, when will we reach the point where those who want to do more than watch kitten videos can function without perpetual trouble shooting.

I don't think Peter's annoyance is unjustified. He had a Mac that ran his projects fine; he bought a better faster one, and it didn't. At this late date, why should he have to delve into the technical details of computing to figure this out? I could have figured this out, and I expect Peter could have too, but should he have to? Maybe he should have stuck with it a little longer. I've had a similar experience with recent OS updates. You get it installed and start thinking about all the stuff that doesn't work as it did and think "do I need this right now?". No: "command-delete". Print the Amazon return address label. Back to useful work.

I blame engineering. Consider the example of cars. Engineers developed standards so that if you mastered a few simple skills, once you drive one car, you can drive any other. If you drive on one road you can drive just about anywhere. It doesn't matter where you go, the basic skills will get you there. We haven't reached that point with computers. Apple had a stab with "just works", but it was little more than a dig at incompetence at MS. I've asked engineers why there is no effective equivalent to SAE in computing. The answer is that people who make computers don't give a #@^*. Someone else will deal with it. Even when they do establish a standard, it doesn't last long. They still think if they do thing differently from everyone else they get some sort of competitive advantage.

Some people enjoy delving into these things, but others look on computers as appliances that sit in the background that should just do what they should. It's good to have people interested in covering for those who make computers. They do a lot of work and don't get paid.

Maybe if we got to the point where it "just works", we could rise to James' goal of spending more our time here telling each other about DP tips.

I wouldn't be so keen to jump on engineering's back. From my experience Marketing is usually what drives shipping a product before it's been properly tested.

Other than that though I would say to you: indeed!

[chokobo99]

]And thus there will always be more of the first group and less of the second. It's been that way since the dawn of time.

From what I've seen on foros, if they aren't tolls, generally it's a function of knowledge. If they don't have it they cannot post much other than to ask for help, but if they do then they can. The choice here maybe altruistic as you say, but it could also just be wanting to interact with people interested in the same area. ¯\_(ツ)_/¯

Also, genetically, humans have evolved to be helpful. Unhelpful humans have to a large extent been selected out, and it is in our nature to want to help others, and this is not limited to other humans. We'll gladly risk our lives to save other animals. And this all stems from a pressure that allowed the human to survive and proliferate.

[chokobo99]

I totally get the "Never use Roland" advice and have been wondering since the Peter's initial post if the Roland stuff he runs might not be the root of his problems. I never again want to have to program an A-800 from a Mac!

PPS: I am reminded how important it is to provide detailed system and usage info when seeking help. Creating a signature with system info is a great start.

I can get this to happen with very low cpu usage synths, for instance the Waldorf PPG plugins are very light on the CPU, but it does take combining them with something more intensive, say Eventide Blackhole, but that's all it takes, and boom red lights.

The problem with sigs is the same as the problem with comments in code. They quickly become outdated, and then create confusion. I've found that the opening post is a proper place to display pertinent information.