What's new

What is causing single core CPU spikes in Logic?

jcrosby

Senior Member
Hi all!

I'm on a 2017 iMac, 3,6ghz i7, 32gb ram, SSD with the latest Mac OS and the latest Logic Pro.

I'm having issues with sudden single core CPU spikes, mostly during live playing of VI's, but occasionally also on playback. The first 7 cores are low but the last one (to the right) suddenly pops to 100% for a second or so causing clicks and pops.

I've tried two different interfaces as well as no interface at all so it does not seem interface-related, but rather something to do with the Mac, Logic, or some plugin I'm using.

I've also tried all variations of the settings for processing threads, process buffer range, and multithreading without result.

I was not expecting performance issues with just a few (5-15) VI tracks on a machine like this. Is this common, and what might be causing it?

Cheers!
Just curioius, did this start after the last OS update? (Or anything else that may have changed in your setup?)
 

sourcefor

Active Member
Yup I get this spike as well with my 2017 MacBook Pro on Sierra..I wish there was a fix other than adding a dummy audio track, which seems to help a bit! I wonder if it’s just Kontakt , etc. and not logic internal instruments? I also get sample rate not recognized errors as well , wtf is with these computers not workin the way they are supposed to.?! My system should be able to handle 20 sample tracks with no problems!
 

jcrosby

Senior Member
Is it safe to go to High Sierra or better to stay on Sierra?
Although I'm not on HS yet, everything I've researched suggests it's basically the same story on 10.12 and 10.13... (the video I linked to was a guy in 10.13... He was also experiencing issues with Keyscape so it's not isolated to Kontakt...)
 

ewtwolf

New Member
Found this video yesterday while trying to decide whether I pull the trigger on the new MBP... Anyway, sounds exactly like what you're describing. He shows it happening cyclically every 60 seconds, even when idle. He also has Console open and looks at all of the processes running...

Although he doesn't have a solution or a solid answer as to which process he's definitely on to something that Apple need to look into... Seems to be OS related, basically a garbage background process chewing up CPU cycles.


That is my video. I have since gotten to the exact issue of why this happens and have a hack for MBP users. I've tested this on both High Sierra and the latest Mojave beta where the battery bug still exists.

So first off, it is important to understand how OSX handles system processes. When these are coded they can be setup as single threaded or multithreaded. The catch is, single threaded processes within the same framework all use the same core. On the development side, this is part of something called a WorkLoop. So for example, most kernel level tasks exist within the Apple IOKit framework as it has the system management bus under its umbrella. This is also where CoreAudio lives. That is key, because it means anything set in code for single thread processing, that is part of the IOKit, all goes on the same core together.

Most low level system processes are single threaded, like the AppleSmartBatteryManager.kext driver, and the BIG issue with Macs and ProAudio work, is active live tracks in your DAW, the one taking active input whether it's midi triggering a soft synth or live audio coming into a FX chain, those processes are single threaded. It's just how the OSX CoreAudio architecture works. By putting the process on a single core, it maintains integrity and things can get done at a lower latency. This is why you see in Logic Pro for example, the first core in its cpu meter running really high for your active track compared to the other core meters. Logic will multithread the other tracks not taking live input. Remember for Logic, the complete signal path of your active track gets put on the first core. So if you have fx on your master bus, those fx get put onto the single core, as do any other buses the track might be routed through.

So this setup typically works ok. The OS system has a scheduler that gets populated from the IOKit workloop, and it assigns the processes to the CPU. So if you look at your console and see all those processes running and notice the time stamp, you see we are dealing with things happening in very small fractions of a second. The scheduler commits processes to the CPU typically in an asynchronous manner, where one driver might have several processes associated with its active cycle, but each of those get layered against others:

Driver1 - Process 1
CoreAudio - Process 1
Driver2 - Process 1
CoreAudio - Process 2
Driver1 - Process 2
CoreAudio - Process 2
Driver2 - Process 2
CoreAudio - Process 3


So in this scenario the time difference from one event to the next is negligible in terms of audio processing. However, some system drivers can lock the core so only their commands get run for its cycle. This is what the battery manager is doing:

CoreAudio - Process 1
SmartBatteryManager - Command 1
SmartBatteryManager - Command 2
SmartBatteryManager - Command 3
SmartBatteryManager - Command 4
SmartBatteryManager - Command 5
SmartBatteryManager - Command 6
SmartBatteryManager - Command 7
SmartBatteryManager - Command 8
SmartBatteryManager - Command 9
SmartBatteryManager - Command 10
CoreAudio - Process 2 - IOWorkLoop - Skipping Cycle due to Overload <--- This would be the moment that the coreaudio exceeded its low latency buffer time and you get an audio dropout

The battery manager is using super old code, from 2005, before we had a lot of multicore laptops. And it uses a poll() coding method that isn't efficient for multicore systems, because it locks out the core, and typically runs a long command cycle. Basically nothing else gets through to the core until it finishes the commands. CoreAudio has a buffer setting, and if you run a low setting, you essentially limit the time it can wait. But since it can't get its process into the cpu core, you receive a Skipping Cycle due to Overload and get an audio dropout and glitch sound.

Other processes can activate that locking priority too, but most run shorter cycles, non poll() methods. But these are things to look into. I try and disable things like iCloud, BlueTooth, wifi, notifications, Siri, etc... Any third party apps like fan controllers, or battery apps, stuff that runs on the System Management Bus (SMBus) will cause issues sharing the core within IOKit workloop tasks.

TL;DR - Ok that out of the way this is the hack:

The MBP battery hack is pretty simple. You will basically trick OSX into thinking you are running a desktop Mac.

First make sure you are plugged into the AC Adapter. You also need to disable SIP (System Integrity Protection) to have access to change the system files. Restart the MBP and hold Command+R before the Apple Logo appears, and boot into Recovery Mode. At the menu bar, select Utilities>Terminal and type this command and hit Return:

csrutil disable

Restart your MBP and login

Open Finder and go to System/Library/Extensions/AppleSmartBatteryManager.kext

Right Click>Rename

Change .kext to .xkext and enter your password

Open Terminal and type this command and hit Return:

sudo kextcache -system-caches

Enter your password

This will flush the driver caches. It takes ~15-20 seconds. You will get a new Terminal prompt when it completes.

Once complete, Reboot your MBP

When you log back in you will no longer have a battery readout. You can verify the hack by opening Terminal and typing this command and hit Return:

pmset -g batt

This typically tells you the state of the battery charge. It should read "AC Power" if the hack worked.

To undo the hack, simply rename the .xkext extension back to .kext, run the kextcache -system-caches terminal command again, and reboot.

***Don't forget to turn SIP back on once you verify the hack, through booting back into Recovery Mode Utilities> Terminal: csrutil enable and Reboot***

So the downsides of the hack is you get no battery status in OSX, so I don't recommend running it while you are on battery power only. You also lose your energy saving features.

The upside is the battery driver doesn't cause the coreaudio dropout in this mode. The battery power state is maintained by an embedded controller in its hardware, so OSX doesn't actually control the charging or power distribution. This is the reason you can charge your MBP with it powered off. Also the thermal management is not affected by this, and the battery temp sensors are still active. I bought a simple usb-c power meter that I connect to my MBP port and plug the power adapter cable into it, giving a readout of the voltage and current. Everything looked normal with ~ 2x more current when the hack was active vs without. Voltage remained constant between both setups.

This is obviously a hack messing around with system files, so do this at your own risk. There is potential here for corrupting the OS or instability. For my system, I've run this setup for several days with no issues. I'm on a 2018 MBP i9 32GB 1TB SSD with a RME BFP.

There are a few other services I've noticed that can cause some coreaudio related issues, and might help desktop users too. These are the watchdog events and apsd (Apple Push Service Daemon). I'm still experimenting with turning those off. I'll report back if I can remove them without any issues.
 
Last edited:

ewtwolf

New Member
Just to clarify, Logic Pro is more likely to encounter the battery issue consistantly every time it runs, since Logic always places the active track onto the same processing core used by the system. Ableton, Cubase, Reaper tend to multithread things a little better, but they don't overlook the system core - all are fair game for getting processes assigned. So potentially the cpu event scheduler could put your Cubase/Ableton active track process onto the same core, and then it gets the overload event when the battery manager driver polling kicks in. So less frequency of the overload with the other DAWs, but still a problem.
 

Saxer

Senior Member
...since Logic always places the active track onto the same processing core used by the system.
I don't think that's the case. It's just the way Logic shows the active core. If you open the Activity Monitor you can see that Logics activity jumps from core to core.
 

ewtwolf

New Member
The Active track that is taking input, is shared on the same core as any IOKit workloop processes. Any additional tracks that aren't actively selected get multithreaded.
 

ewtwolf

New Member
Also, yes the core in use for single core processes can change, The Logic meter isn't a direct representation to the cores shown in the ActivityMonitor. However, once the event scheduler assigns the process to a core, the process stays there. So yes, you would see the cpu movement on different ActivityMonitor cpu meters, some of that is multithreaded background Logic Pro processes, and some is other system stuff. Active track processes will be confined to one core tho, whichever one the scheduler assigns it too, at the same time and core it assigns anything else in the IOKit workloop. Other system processes not in the IOKit framework might get scheduled onto different cores at the same time, depending on their scheduler:

Page 78 talked about WorkLoops within the IOKit framework:
WorkLoop Apple Dev Documentation

IOAudioEngine Documentation

One of several source code files for the battery manager showing poll() method and workloop.
AppleSmartBatteryManager.cpp

Interesting read on CoreAudio and different buses p26

AppleSmartBatteryManager uses this:
command gate: A mechanism that controls access to the lock of a work loop, thereby serializing access to the data involved in I/O requests. A command gate does not require a thread context switch to ensure single-threaded access. IOCommandGate event-source objects represent command gates in the I/O Kit.

IOKit single-thread stuff all goes into the same workloop:
workloop: A gating mechanism that ensures single-threaded access to the data structures and hardware registers used by a driver. Specifically, it is a mutex lock associated with a thread. A work loop typically has several event sources attached to it; they use the work loop to ensure a protected, gated context for processing events.
 
Last edited:

jcrosby

Senior Member
That is my video. I have since gotten to the exact issue of why this happens and have a hack for MBP users. I've tested this on both High Sierra and the latest Mojave beta where the battery bug still exists.

So first off, it is important to understand how OSX handles system processes. When these are coded they can be setup as single threaded or multithreaded. The catch is, single threaded processes within the same framework all use the same core. On the development side, this is part of something called a WorkLoop. So for example, most kernel level tasks exist within the Apple IOKit framework as it has the system management bus under its umbrella. This is also where CoreAudio lives. That is key, because it means anything set in code for single thread processing, that is part of the IOKit, all goes on the same core together.

Most low level system processes are single threaded, like the AppleSmartBatteryManager.kext driver, and the BIG issue with Macs and ProAudio work, is active live tracks in your DAW, the one taking active input whether it's midi triggering a soft synth or live audio coming into a FX chain, those processes are single threaded. It's just how the OSX CoreAudio architecture works. By putting the process on a single core, it maintains integrity and things can get done at a lower latency. This is why you see in Logic Pro for example, the first core in its cpu meter running really high for your active track compared to the other core meters. Logic will multithread the other tracks not taking live input. Remember for Logic, the complete signal path of your active track gets put on the first core. So if you have fx on your master bus, those fx get put onto the single core, as do any other buses the track might be routed through.

So this setup typically works ok. The OS system has a scheduler that gets populated from the IOKit workloop, and it assigns the processes to the CPU. So if you look at your console and see all those processes running and notice the time stamp, you see we are dealing with things happening in very small fractions of a second. The scheduler commits processes to the CPU typically in an asynchronous manner, where one driver might have several processes associated with its active cycle, but each of those get layered against others:

Driver1 - Process 1
CoreAudio - Process 1
Driver2 - Process 1
CoreAudio - Process 2
Driver1 - Process 2
CoreAudio - Process 2
Driver2 - Process 2
CoreAudio - Process 3


So in this scenario the time difference from one event to the next is negligible in terms of audio processing. However, some system drivers can lock the core so only their commands get run for its cycle. This is what the battery manager is doing:

CoreAudio - Process 1
SmartBatteryManager - Command 1
SmartBatteryManager - Command 2
SmartBatteryManager - Command 3
SmartBatteryManager - Command 4
SmartBatteryManager - Command 5
SmartBatteryManager - Command 6
SmartBatteryManager - Command 7
SmartBatteryManager - Command 8
SmartBatteryManager - Command 9
SmartBatteryManager - Command 10
CoreAudio - Process 2 - IOWorkLoop - Skipping Cycle due to Overload <--- This would be the moment that the coreaudio exceeded its low latency buffer time and you get an audio dropout

The battery manager is using super old code, from 2005, before we had a lot of multicore laptops. And it uses a poll() coding method that isn't efficient for multicore systems, because it locks out the core, and typically runs a long command cycle. Basically nothing else gets through to the core until it finishes the commands. CoreAudio has a buffer setting, and if you run a low setting, you essentially limit the time it can wait. But since it can't get its process into the cpu core, you receive a Skipping Cycle due to Overload and get an audio dropout and glitch sound.

Other processes can activate that locking priority too, but most run shorter cycles, non poll() methods. But these are things to look into. I try and disable things like iCloud, BlueTooth, wifi, notifications, Siri, etc... Any third party apps like fan controllers, or battery apps, stuff that runs on the System Management Bus (SMBus) will cause issues sharing the core within IOKit workloop tasks.

TL;DR - Ok that out of the way this is the hack:

The MBP battery hack is pretty simple. You will basically trick OSX into thinking you are running a desktop Mac.

First make sure you are plugged into the AC Adapter. You also need to disable SIP (System Integrity Protection) to have access to change the system files. Restart the MBP and hold Command+R before the Apple Logo appears, and boot into Recovery Mode. At the menu bar, select Utilities>Terminal and type this command and hit Return:

csrutil disable

Restart your MBP and login

Open Finder and go to System/Library/Extensions/AppleSmartBatteryManager.kext

Right Click>Rename

Change .kext to .xkext and enter your password

Open Terminal and type this command and hit Return:

sudo kextcache -system-caches

Enter your password

This will flush the driver caches. It takes ~15-20 seconds. You will get a new Terminal prompt when it completes.

Once complete, Reboot your MBP

When you log back in you will no longer have a battery readout. You can verify the hack by opening Terminal and typing this command and hit Return:

pmset -g batt

This typically tells you the state of the battery charge. It should read "AC Power" if the hack worked.

To undo the hack, simply rename the .xkext extension back to .kext, run the kextcache -system-caches terminal command again, and reboot.

***Don't forget to turn SIP back on once you verify the hack, through booting back into Recovery Mode Utilities> Terminal: csrutil enable and Reboot***

So the downsides of the hack is you get no battery status in OSX, so I don't recommend running it while you are on battery power only. You also lose your energy saving features.

The upside is the battery driver doesn't cause the coreaudio dropout in this mode. The battery power state is maintained by an embedded controller in its hardware, so OSX doesn't actually control the charging or power distribution. This is the reason you can charge your MBP with it powered off. Also the thermal management is not affected by this, and the battery temp sensors are still active. I bought a simple usb-c power meter that I connect to my MBP port and plug the power adapter cable into it, giving a readout of the voltage and current. Everything looked normal with ~ 2x more current when the hack was active vs without. Voltage remained constant between both setups.

This is obviously a hack messing around with system files, so do this at your own risk. There is potential here for corrupting the OS or instability. For my system, I've run this setup for several days with no issues. I'm on a 2018 MBP i9 32GB 1TB SSD with a RME BFP.

There are a few other services I've noticed that can cause some coreaudio related issues, and might help desktop users too. These are the watchdog events and apsd (Apple Push Service Daemon). I'm still experimenting with turning those off. I'll report back if I can remove them without any issues.

Small world :) Thanks so much for posting this. I bought an i9 Friday, waiting for it to arrive... Definitely good advice, I'd clone or TM my system before monkeying with an system level kext files anyway... Also great pointers about other background processes. I disable just about everything you mentioned, however I typically run iStatMenus to monitor temperature. Looks like I'll skip installing it, at least for the time being... Much appreciated.

I also wonder if this is part of Logic's longstanding One Core Curse? I.e. if it uses the same core as background processes it seems like it should be related, and perhaps updating Logic's code so that it prevents it from using the core designated for background processes as a core available for active tracks...

Have you spoken to anyone at Apple about this? I'd imagine if you contacted their Pro Apps department they'd do the best they could to get some eyes on the issue.

Also curious... Assuming you've worked previously on MBP's, wondering if you find you get a higher overall instrument/plugin count, (in terms of CPU efficiency), on the i9 than previous MBP models. (Disregarding the dropout issue obvioulsy...) If so, curious if you think it's a subtle improvement, or fairly substantial?

Cheers, and thanks again for all the research...
 
Last edited:

ewtwolf

New Member
Yeah, I submitted a bug report through their development side, #43737017, related to testing this on Mojave 10.14, but mentioned it also exists in High Sierra. They did respond asking for additional system logs. I also had a support request through Logic Pro and spoke several times with a senior specialist there named Chris. I sent him my video, and he took detailed notes, and passed it on to the development team. He's been great, even calling me when the latest MBP firmware came out to test if it fixed things -- unfortunately it did not.

So the issue is in part how Logic is coded, but more an OSX architecture issue. Logic Pro puts anything that the live active track's signal goes through on the same core. So any fx, even if they are on other buses, all get processed on the same core. This is really due to the OSX IOKit framework. Without seeing the actual source code for the various DAW's, it's hard to tell what they do different. I would guess maybe the buffering is better in other DAWs -- Cubase for example with its ASIO guard. Or maybe it is somehow they multithread the signal chain better. Or maybe set their thread priority differently. It looks like based on Apple dev docs that real-time audio will always be on a single core shared with the IOKit system bus processes, it is just a matter of if that single core is also running other higher priority system tasks that run longer than the audio buffer. If you are interested, this video is a presentation from one of two original architects of the IOKit framework. He explains how the priority bands and workloop function from a driver perspective
This link has the slides he used: http://www.cse.unsw.edu.au/~cs9242/06/lectures/09-IOKit_Threading.pdf Interestingly at 29:35 he mentions that using the poll method is not recommended. Which is what the battery manager uses. I think whichever third party supplier designed the battery controller chip, also did the poor code.
 
Last edited:

sourcefor

Active Member
Thanks for all this info, I guess we just have wait for a recode of logic ?? Does anyone also get MIDI timeout issues and how do you correct this as well. Sorry to hijack but you guys seem to know whats going on.?!!
 
OP
mybadmemory

mybadmemory

Senior Member
Thread starter
  • Thread Starter
  • Thread Starter
  • #35
I just noticed that my singe core SPU spikes are MUCH worse after waking the computer up from sleep than after a full reboot. It does however get substantially better if I just restart CoreAudio by changing the buffer size and hitting Apply.

Nice to have found a "fix", but still annoying to have to do this every time I wake the computer up (since I pretty much never turn it off but rather send it to sleep).

Have anyone else noticed this? Could any of the energy saving settings affect that some process need to restart after sleep?
 

ewtwolf

New Member
I haven't noticed that, but I have noticed Safari is a turd with CoreAudio. I do not recommend having it open in the background, and definitely not browsing with it while streaming audio, like youtube or iTunes. I get a lot of dropouts even with my battery hack with Safari running. Seems like the webkit services Apple has for Safari can overload CoreAudio. I've been trying the Opera browser without any issues. Haven't tried the others like Chrome or Firefox yet.
 

ewtwolf

New Member
Even with the battery hack, bigger sets in Ableton are still glitching out with CoreAudio overload events. I've tried turning off additional services through Terminal, but things just get too unstable. OSX just needs a major overhaul for CoreAudio. What a pain digging into all this. So the best fix I have found is installing Windows 10 Pro through Bootcamp. Rock solid. Seriously, no glitches, no hacks needed. 64 sample size buffer in Ableton runs perfect with my RME BFP. I guess I now own a very expensive Windows laptop. Hopefully Apple gives the bugs some serious work, otherwise I'm calling it, Pro Audio DAW work on a Mac just sucks. Bootcamp was a turd to install too. The software kept timing out on download through the Bootcamp assistant. Now that it is installed though Windows works awesome. Left a 200GB partition for OSX in case I need to install another firmware update.
 

mc_deli

n trepreneur
Use fewer auxes, delete all bus plug ins... delete all auxes when you get desperate... don't use multi instruments... because they make auxes... and they pile it on core 1...

I'm surprised by the OP. This has been around for ages and I have read hundreds of posts on it. The hack is new, though that is too saucy for me!
 

ewtwolf

New Member
I did a quick 1:30ish video covering my MBP and Mac general OS X hacks to minimize background processes causing CoreAudio issues. I'm able to run a decent sized Ableton session at 64 sample buffer, while QT screen capturing no less. Hope this helps out anyone with OS X woes.

 
Top Bottom