Ableton 12 and the use of efficiency and performance cores on M-processors

[Shadowfigure]

I'm on an M3 Max with 128 GB of RAM, fully upgraded to the top CPU spec. I can confirm the Efficiency cores aren't being used and I'm waiting around for Live to bounce tracks for a mixdown in Ableton Live 12 Suite.

For those arguing against "the need" for it, it's not about whether you're maxing out the CPU and causing issues, it's about rendering audio faster for me. This machine is extremely powerful and I shouldn't be waiting 30 minutes to render 20-30 stems if all the resources were efficiently being used. I spent way too much money on this computer, and my main use case is for music. Learning about this software-related limitation is extremely disappointing.

Please consider enabling the use of all of my machine's resources to make working in Live faster and more efficient, so I can get on with my mixdown.

Thanks for your consideration.

[Leborgnew]

Hi there,

Here are some inputs to summarize and try to clarify this whole subject !

The way audio is processed WITHIN Apple Silicon devices (using Audio WorkGroups) leads to an issue for some audio apps :

THE ISSUE

It has been an ongoing problem for a while on Apple Silicon machines (probably since MacOS Ventura, as we did not experience this issue with our initial Apple Silicon benchmark on Big Sur and Monterey) – Intel systems are currently not impacted. The symptom is that you get random audio dropouts in some audio apps, especially when working under low CPU load (yeah, this does not sound intuitive, but that’s the reality!).

This only happens for audio apps which perform parallel audio processing to get the best out of modern CPUs that are capable of working simultaneously on multiple tasks, and rely on Apple’s Core Audio to work with audio devices. You may typically have experienced the problem with our apps and plug-ins that have the multicore option, such as PatchWork, Axiom, MB-7 Mixer or Late Replies. But some major DAWs have been impacted too (I have seen some official advice about reducing the buffer size to fix it – forcing the CPU to work harder and actually increasing CPU load).

THE ROOT CAUSE

Apple Silicon processors are asymmetric: they have both efficiency cores (E-cores), suitable for background tasks with low processing demands, and performance cores (P-cores), designed for heavy-duty processing tasks. This requires different scheduling for real-time tasks (tasks that have to be executed with time constraints, such as real-time audio), and others.

There have been already a few things available for developers to tell the system about the type of tasks they are doing, but they do not seem to be used by MacOS (although the features are available in the Unix parts of MacOS – namely pthreads), as setting these properties seems to have absolutely no impact on their scheduling in audio apps.

In 2020, with the release of the M1 processor and MacOS 11 (codename Big Sur), Apple introduced a new concept called “Audio WorkGroups” for this purpose (which has some advantages over the forementioned solutions for sure, but also has limitations, and require some impacting new developments for apps an plug-ins developers).

So, as described by Blue Cat Audio, workarounds are possible but require "impacting new developments".

As far as Blue Cat is concerned, this has led him down paths he doesn't feel entirely safe about :

After a deep journey in the public MacOS source code to try to understand how to use these Audio WorkGroups properly, a generic solution for all cases was found! Well… it is actually a “hack”, as it relies on how Workgroups are implemented in the MacOS system: it is always a bad idea to rely on the undocumented implementation of a feature, but in this case Apple gives us no choice. And for this particular piece of code, it seems pretty safe to rely on it (it is not likely to break, and has not changed at all since it was added, remaining stable for 4 versions of the system).

Here is the approach taken by Ableton (for now) :

PERFORMANCE AND EFFICIENCY CORES ON APPLE SILICON

If you compare the idle performance of Live 12.0 or 11.3.25 with earlier versions on an Apple Silicon computer, you might notice a higher % CPU value in Activity Monitor. This is because while Silicon Macs offer both performance cores and efficiency cores, Live attempts to schedule all audio threads on performance cores, to ensure consistent and predictable performance. This may result in a higher percentage of the relevant cores being used, and thus a higher value listed in % CPU. This increase may be expected, and does not necessarily indicate a problem with Live.

If you’d like to revert to Live’s prior behavior for handling performance cores, an Options.txt entry (-DisableAppleSiliconBurstWorkaround) is available. Please test Live's performance and try optimizing CPU usage following the other tips in this guide, if needed, before installing this option.

I'm sure Ableton's fellow developers know what they're doing ; if they have chosen the route described above, there is no doubt this is the best way for us to enjoy Live for the moment (May 2024).

If you still want to "enable the use of all your machine's resources", Ableton let you the option to make use of both performance and efficiency cores by disabling the aforedmentionned "Apple Silicon Burst Workaround", but keep in mind this could be at the expense of Live stability.


PS : bold and underlining in quotes are additions of my own, please follow links for original formatted text.

[Machinesworking]

I've tested this on the 7 or so DAWs on my system. For the most part "real time" DAWs like Live, Bitwig etc. are not using Efficiency cores whereas ones with secondary buffers to improve track counts like Reaper and Digital Performer are. I don't know if there's any way to track exactly what these DAWs are doing but it's very likely that they bounce "pre rendered" tracks ( tracks without record enable that you currently are not controlling with hardware control surfaces etc.), to Efficiency cores. This isn't something that Live can do so.... For the record Logic also does not use Efficiency cores, but I have to say in that case I just don't get it, the difference in track counts in performance tests is 106 Logic to 140 Reaper and DP. Live comes in around 90. 90 to 106 is the smallest gap I've ever seen between Logic and Live, it doesn't seem to be getting much benefit from it's secondary buffers on APple Silicon either.

[H20nly]

Live comes in around 90. 90 to 106 is the smallest gap I've ever seen between Logic and Live, it doesn't seem to be getting much benefit from it's secondary buffers on APple Silicon either.

This sounds about right to me. Once I top 100 tracks in Live the slow load/close times, CPU meter crying, and the need to set my buffer to 2048 to mix starts kicking in. It’s to the point where I’m probably not going to start any new tracks with Live. I’m basically using Cubase as a workaround with Luna and Logic on standby. I have about 10 - 12 tracks close to finished in Live. After that I think I’m throwing the towel in. Hell, you can hardly even get a ‘need help’ type question answered on the forum anymore. It’s not just the software

[[jur]]

you can hardly even get a ‘need help’ type question answered on the forum anymore.

What do you mean?

[H20nly]

you can hardly even get a ‘need help’ type question answered on the forum anymore.

What do you mean?

Really? Well, ignoring all the other users’ unanswered pleas for help and/or guidance, here’s an example of me being stopped in my tracks trying to finish up a mix…

viewtopic.php?p=1825145#p1825145

Crickets