Native M1 plugins are NOT handled natively in Logic Pro ? (AuHostingService)

[bontempi]

Hi

When i put a native M1 plugin in logic, a lot of them start with a small window that expands to a big regular one. This feels quite bizarre, like there's some conversion going on behind the scene, even though the plugin is native.

Now i've noticed something in activity monitor : as SOON as you launch a M1 arm native third party plugin, a process appears, named AUHostingService (Logic Pro). This process is the one using the CPU for the third party plugin, not Logic Pro. It actually uses more CPU than Logic in my last session.

If you run Logic Pro in rosetta mode, the AUHostingService process never shows up, no matter which plugin you run.

While i can understand this process would show up for plugins that are NOT native, why does it handle CPU performance for native ones ?? Can't logic handle this by itself ? Can someone explain ?

As a few other people here, i've been having issues with my M1 macbook pro in logic, and i'm wondering if the Logic we've been using is just a bad beta version... This feels really amateurish

Thanks

 

[UBS28]

I have no idea why this happens. I checked on mine and I also get this when I load M1 native plugins.

There is some weird **** happening with M1 Max + Logic Pro. If I have a project that stresses 1 of the cores to the maximum, there is a high probability that all audio seizes to work and the only way to fix it is to restart my MAC.

I guess it is still "beta" indeed.

 

[bontempi]

you can check this video to improve performance a bit

Never had to change settings like that before.....

 

[aramism]

I have a mac studio m1 max 32gb ram and can confirm my 2008 mac pro (which I replaced with this "supercomputer"4 which isn't super) isn't that far behind

even "native" m1 plugins run like crap tbh

bottom line I think M1/2 are ahead of their time and it may take years for us to get to the point in the audio world where the performance of M processors running heavy duty pro level audio projects can match the best intel machines now. As stated above, my 2008 mac pro (which was the best at the time and was as maxed out as could be) wasn't really too much slower than this current mac studio. For sure there is a noticeable difference but there would have been with a trashcan mac pro also. The mac studio makes me appreciate the older mac pros even more. I open VERY LARGE projects now which I mixed on my old system and the amount of additional CPU headroom I get is minor.

At least the mac studio is relatively cheap lol

Def not for real pro use though. I'll be waiting for the mac pro and see how that is or maybe get a 2017 imac pro intel instead b/c I know people who have them and they smoke the mac studio for audio applications

 

[galad]

Because it was a good chance to switch to out of process plugins and probably to a newer audio unit format (the same used on iOS probably). Plugin already had to be recompiled, so it was a good time to make a bunch of additional small changes.
Moving them to another process means better crash protection.

 

[MajorFubar]

Yeah I think I jumped ship too early too. Before April I had a perfectly reliable system based around a maxed-out 2011 iMac running High Sierra, owned since nearly new.
With an M1 Max processor in my Mac Studio my life should have been a dream, but the reality is plugins don't always work properly (and yes they all open first in that funny little weird window), I can't update the firmware in my control surfaces because the software to do so is not M-compatible, and Logic can drop connection to my audio interface and control surfaces multiple times an hour, for a reason I have yet to establish.
I realise now I got too-easily taken-in by the hype and I should have just bought myself a loaded Intel Mini and waited five years for the dust to settle.

 

[Zest28]

I also have 1 annoying plugin which is crapping out my 16” M1 Max MacBook Pro like no other. I have talked with the developer about this and they blame Apple.

So I will just wait and see what happens in terms of updates.

 

[aramism]

Yeah I think I jumped ship too early too. Before April I had a perfectly reliable system based around a maxed-out 2011 iMac running High Sierra, owned since nearly new.
With an M1 Max processor in my Mac Studio my life should have been a dream, but the reality is plugins don't always work properly (and yes they all open first in that funny little weird window), I can't update the firmware in my control surfaces because the software to do so is not M-compatible, and Logic can drop connection to my audio interface and control surfaces multiple times an hour, for a reason I have yet to establish.
I realise now I got too-easily taken-in by the hype and I should have just bought myself a loaded Intel Mini and waited five years for the dust to settle.

exactly. In hindsight I should have, for the same price, bought a used (some even with apple care on it) or certified owc imac pro from 2017. Or my initial idea, for much less money, which was to get a 5,1 (I had a 3,1) and load it up with the fastest drives and ram and get by for a 3-4 more years until I got a new mac pro. I bet the 5,1 loaded would in real world settings perform right around where the mac studio is now!


I'm jealous of the colleagues I know who have it and opening same projects on theirs is waaaaay better. Even in "native" mode with all "native" plugins my mac studio craps out disturbingly early and yes I've seen all the videos and tried changing all the settings. They help a bit but even with them optimized it still performs how I'd think a macbook pro from 2015 or something would.

The most remarkable thing is how solid my old 2008 mac pro is. Depiste the benchmarks and geekbench etc, etc, for M1 being so high, in real world use, it frankly SUCKS.


All these tech bros who review it and benchmark it do so in non real world ways. No one will ever load 500 instances of the logic stock reverb or exs24 or kontakt. In reality, people mix and match different plugins and the diversity of the tracks and material creates much more cpu load than just duplicating tracks over and over to see how many max tracks it can load. I have a (by modern standards) low track count mix that I had to freeze tracks on to finish.

I attached a screen shot. As you can see, it's a very average modern song. I've mixed songs with way more tracks and plugins in the past. This is something I'd consider "simple" by pop standards. And again, it keeps overloading so I have to freeze tracks!


I should also note that the same process which I didn't see on Intel that runs called "auhostingservice" and "auhostingcompatibilityservice" which use a ton of CPU in the activity monitor. Not sure what that's about. Maybe activity monitor is counting the plugins themselves as a separate thing than logic?

 

[mr_roboto]

I should also note that the same process which I didn't see on Intel that runs called "auhostingservice" and "auhostingcompatibilityservice" which use a ton of CPU in the activity monitor. Not sure what that's about. Maybe activity monitor is counting the plugins themselves as a separate thing than logic? View attachment 2044995

The AU (Audio Unit) plugins are being run in a separate UNIX process from the main Logic process, AUHostingService. It's using a lot of CPU because your plugins do most of the work.

Due to the way Rosetta works, native Arm code and x86 code cannot coexist in the same UNIX process. That's what the second AU hosting process, AUHostingCompatibilityService, is for - it's the same thing as AUHostingService, but launched in x86 mode to host x86 plugins. Both hosting processes communicate with the main Logic process through some form of IPC (inter-process communication) - probably a shared memory scratchpad for speed.

A long time ago, Audio Units were loaded in the same process as the application using them. Several years before the Apple Silicon announcement, Apple began transitioning to a new plugin architecture where AUs (and other kinds of plugin) run in a separate process. Now we have a reasonable idea as to one of the goals of this change, which was somewhat unnecessary at the time - it allowed them to provide a way for old x86 plugins to work in Arm-native apps.

That said, things might get better for you if you can figure out which plugins aren't native code and try to update or replace them. Compatible doesn't mean works perfectly.