Live 12 empty set eats 53% CPU/kills battery on M1Max at idle

[rgarner]

As subject, an empty Live 12 set eats 51% CPU in Activity Monitor on an M1Max Macbook Pro constantly. It's not the Ableton Indexer process, which takes 100% at startup and then disappears. It's the main Live process. I can no longer use Live without being plugged in, because this absolutely demolishes my battery.

I've submitted to support but they'll be inundated so I'd just like to know: anyone else seeing this?

PS If I launch under Rosetta the CPU "only" takes 37% at idle (but for some reason the licensing system eats another authorisation for this).

[nicobi]

Yes, this behavior has ben present in the betas too. In my case (M1Max, latest macOS 14.4) L12 yields an idle activity around 45% - 55%. It is not quite clear to mee if this is a „bug” (which I reckon it isn't) or a temporary behavior in which the Live process executes a phantom process to force usage of P-cores. There has been discussion about the CPU core utilization which appears to be a problem with the Live audio engine and is not a problem in other DAWs.

Unfortunately Ableton engineering has not relesed any statement on the matter to my knowledge. Therefore the best option is to file a support report with all relevant data to Ableton.

See also viewtopic.php?t=248739

[lincolnkid]

I reported this, and here’s the response I got, slightly edited…

In Live 12 and now 11.3.25 we have restricted Live from scheduling work to the E cores and prioritize the P cores only to maximize performance at the expense of energy usage.

If you want to revert back to the behaviour prior to Live 11.3.25 you can put
-DisableAppleSiliconBurstWorkaround
in your Options.txt file.

With the previous implementation, Live could schedule to E cores at higher buffer sizes if the processing had the potential to be handled by slower, more efficient E cores. This created a performance issue where CPU usage was often higher at higher buffer sizes and less dependable.

Live's audio engine now favours realtime performance (especially for live performance and studio scenarios) and maximizes the processing power of Apple Silicon P cores to deliver the lowest CPU usage possible at all buffer sizes, at the expense that you will see higher energy usage and CPU usage in the activity monitor.

The result is: If you have a heavy set with lots of tracks, processing and latency, you'll most likely have a much better result when running at buffers like 1024 and 2048 samples and be able to get more juice out of the CPU.

[nicobi]

Ok. The reply then makes it clear that this is a workaround - as the code in the options textfile is denoted as that and the scheduling of P and E - cores is moved to a hard xor line of code in the options textfile, which raises the question of technical depth of the Live audio engine.

[madlab]

Well, that is assuming that if cpu goes up when this is deactivated an empty set consuming 55-60% of the cpu would be something desirable.