CPU usage in Live 10

[spendthrift2]

Switching to ASIO4ALL made a world of difference. Here are the instructions I followed.
https://www.sweetwater.com/sweetcare/ar ... r-windows/

Additionally my CPU was still freaking out a little bit (crackling and dropping out) after I downloaded ASIO4ALL; just not as much. It turns out my processor state was not correctly configured.

To check this, (Windows 10)

Go to Settings from the start menu.

Click on the System Settings.

Select Power & Sleep.

On the right side of the screen select Additional Power Settings.

Under selected plan choose Change Plan Settings.

Select Change Advanced Power Settings.

Expand Processor Power Management.

Expand Minimum Processor State. Increase the value to 100% for both battery and when plugged in.

Expand Maximum Processor State. Increase the value to 100% for both battery and when plugged in.

This completely fixed my CPU issues. I have an i5 processor, which is supposed to work for Ableton. I was getting so mad when it wasn't working and thanking my stars that it was only the 30 day trial/that I hadn't jumped in head first! But this procedure fixed everything. The only thing about it is it obviously could potentially influence battery performance such that I am advised to keep my laptop plugged in when I'm working on music in Ableton.

[mcclaine]

Hi Mcclaine,

I had a few CPU issues with Live when I first got my new Windows 10 laptop. I made a few changes and it is now running great.

The following might help.....

https://support.focusrite.com/hc/en-gb/ ... Windows-10

Thanks for your reply, i will read that thread

[mcclaine]

Switching to ASIO4ALL made a world of difference. Here are the instructions I followed.
https://www.sweetwater.com/sweetcare/ar ... r-windows/

Additionally my CPU was still freaking out a little bit (crackling and dropping out) after I downloaded ASIO4ALL; just not as much. It turns out my processor state was not correctly configured.

To check this, (Windows 10)

Go to Settings from the start menu.

Click on the System Settings.

Select Power & Sleep.

On the right side of the screen select Additional Power Settings.

Under selected plan choose Change Plan Settings.

Select Change Advanced Power Settings.

Expand Processor Power Management.

Expand Minimum Processor State. Increase the value to 100% for both battery and when plugged in.

Expand Maximum Processor State. Increase the value to 100% for both battery and when plugged in.

This completely fixed my CPU issues. I have an i5 processor, which is supposed to work for Ableton. I was getting so mad when it wasn't working and thanking my stars that it was only the 30 day trial/that I hadn't jumped in head first! But this procedure fixed everything. The only thing about it is it obviously could potentially influence battery performance such that I am advised to keep my laptop plugged in when I'm working on music in Ableton.

Thanks! i will try both ASIO4ALL and the setting changes

[Stace30]

I didn't need to switch to ASIO4ALL (although, if that works then do it), I just used the ASIO Focusrite drivers I use with the interface and then if you follow the options that spendthrift2 has said, you should be good to go (as that's more or less whats said in the link that I gave you). It all worked well for me, good luck.

Al

[flosstradamus]

Does anyone know if there is a setting in options.txt to help out with these cpu spike issues??

[Stromkraft]

Does anyone know if there is a setting in options.txt to help out with these cpu spike issues??

Why would there be? This is a low level interplay with hardware and OS routines.

[Biome Digital]

the "120Hz refresh rate bug! had me for a long time! lol CPU is Ok though.

[Timbaman]

This was my case scenario:

Windows 10, clean install, no gfx card, I7-8700, Focusrite Scarlett USB interface ASIO drivers, Windows defender antivirus.

In Live 9 everything was normal, no CPU spikes/overload.
In Live 10 CPU spikes and overall higher CPU usage , crackling etc., for the same project.
Even when idle (no tracks, no VSTs loaded, nothing playing) I had 3-5% CPU usage reported in Live 10.
Only loading certain VSTs (not even playing them) would increase CPU usage to 40%, as reported by Live.
Resource monitor in Windows would always report much smaller CPU usage.

Problem was solved by applying the advice from a user couple of pages before - setting the minimum processor state to 100%, now everything works fine.
I'm using the free "Process Lasso" program to set Live 10 as a High Performance Program, to avoid driving the CPU at 100% when not using Live.

So, the problem is with Live 10 multicore support (not playing well with Windows 10 CPU power state management).

[fishmonkey]

Resource monitor in Windows would always report much smaller CPU usage.

this is to be expected, as Live's "CPU meter" is does not show the % of overall CPU cycles being used.

[TLW]

Resource monitor in Windows would always report much smaller CPU usage.

this is to be expected, as Live's "CPU meter" is does not show the % of overall CPU cycles being used.

On a Mac it’s an even less helpful indicator of what’s going on.

When Live 10 reports around 34-38% cpu usage High Sierra reports total cpu usage as around 125-130%*, with Live using the vast bulk of that.

It would be very useful if Live handled this the way Logic, Sonar etc. do and shows cpu usage per core/virtual core rather than a single pretty meaningless “total”.

*Note - on Macs cpu usage is shown differently to how Windows does it. A hyperthreading i7 Mac running flat out with 8 “real” and “virtual” cores would be shown as having cpu usage of 800%. As in 8 cores each at 100%.

[fishmonkey]

Resource monitor in Windows would always report much smaller CPU usage.

this is to be expected, as Live's "CPU meter" is does not show the % of overall CPU cycles being used.

On a Mac it’s an even less helpful indicator of what’s going on.

that's not true actually. there would be less confusion if Ableton didn't refer to it as a "CPU meter". it's actually an audio processing meter, which gives you an idea about how well your machine is coping with the current audio processing load. i.e., how close the most heavily-loaded CPU core is to failing to process it's audio-related calculations quickly and reliably enough, and therefore causing an audio glitch.

if any one of your CPU cores is overloaded, then you will get a glitch, no matter how many cores your machine has. if you have a 100 cores, and only one track in Live, then overloading that one track and core could cause a glitch, even though your overall CPU usage is only at about 1%. that's why a regular CPU meter that actually shows overall CPU usage isn't very useful in this context.

it also means that if Live's "CPU meter" is showing 80% with only one track, you could duplicate that track multiple times with little effect on the "CPU meter", as long as the new tracks are being assigned to different CPU cores.

another thing is that even if all your CPU cores are lightly loaded, you could still have glitches if the processing of audio on even one core is delayed by another piece of software running on your machine.

[H20nly]

there would be less confusion if Ableton didn't refer to it as a "CPU meter". it's actually an audio processing meter, which gives you an idea about how well your machine is coping with the current audio processing load. i.e., how close the most heavily-loaded CPU core is to failing to process it's audio-related calculations quickly and reliably enough, and therefore causing an audio glitch.

if any one of your CPU cores is overloaded, then you will get a glitch, no matter how many cores your machine has. if you have a 100 cores, and only one track in Live, then overloading that one track and core could cause a glitch, even though your overall CPU usage is only at about 1%. that's why a regular CPU meter that actually shows overall CPU usage isn't very useful in this context.

it also means that if Live's "CPU meter" is showing 80% with only one track, you could duplicate that track multiple times with little effect on the "CPU meter", as long as the new tracks are being assigned to different CPU cores.

another thing is that even if all your CPU cores are lightly loaded, you could still have glitches if the processing of audio on even one core is delayed by another piece of software running on your machine.

posted again for posterity.

[teerio]

Hi guys!

I've been trying to solve this CPU overload issue also in my MBP and I've been looking all kinds of forums around the net for help.

Today I found this GS thread where this text by Zenwolf caught my eyes:

"I've gotten to the root of the issue and submitted an Apple Dev Bug Report. The AppleSmartBatteryManager driver is part of the IOKit framework, as is CoreAudio. The IOKit has an associated WorkLoop which is basically a que of background tasks it runs. When these are single threaded, like the polling method the Battery Manager uses for its CommandGate checks, or running the active live track in Logic, they exist on the same core, and basically get lined up to run in the WorkLoop. However, the Battery Manager gets priority based on its Command checks. It locks out the core for its cycle. So when a low latency single threaded coreaudio event happens at the same time, you get the skipped cycle error, and then the coreaudio stream can overload producing the audio dropout. You can avoid it by running a higher CoreAudio buffer sample, but if the CPU load is high enough on your audio process, it can still conflict and overload.

Apple did respond for additional diagnostic info, and I also spoke with Logic support and gave them the same details. I even spoke with RME since I initially thought it was exclusive to their driver. Hopefully it gets addressed in some form. To me moving it off the shared WorkLoop, or giving CoreAudio priority should solve it. I verified the bug by disabling the battery manager and the problem went away. Not a fix though, since you cannot get battery health status and have safe guards against overheating or overcharging."

Thread in GS: https://www.gearslutz.com/board/music-c ... d-bug.html
Another interesting read about this that eventually lead me to GS: https://openradar.appspot.com/43737017

So in this case even though Live then is more hungry with CPU than 9 the problem might lie in the MacOS instead of solely in Live.

Thought that you would be interested about this since there has not been any new information about this problem for awhile.

Cheers,

T

[fishmonkey]

thanks for the info. essentially the Mac OS equivalent of a DPC latency issue on a Windows machine...

[chris vine]

Live 10 still spike-ing out the CPU meter and producing audio glitches. I stripped my live set down and no change. The spikes tend to start after 20 minutes or so. Got some 32 bit VSts being jbridged - each instance of which, according to process lasso, uses up CPU.
I use a lot of long delays and freeze delays/reverbs plus a couple of loopers - often at the same time, so I thought maybe it's too much for the CPU - but I never had this with Live 9 32 bit and 64 bit. All seems to be Live 10 unfortunately.