I’m looking for other MacBook Pro users to verify a CoreAudio overload bug that occurs in both High Sierra 10.13.6 and the latest Mojave Beta 10.14. I’ve tested a new MBP 2018 with the i9 cpu, 32GB ram, 1TB HDD, and a late 2013 MBP & 2011 MBP. All running High Sierra.
The issue involves a background kernel process called the AppleSmartBatteryManager. On my systems, it runs a diagnostic poll of the battery status every 60 seconds. Regardless of being plugged into the AC adapter. This event creates a CPU spike that can overload your CoreAudio and cause a dropout/glitch sound. Typically because most pro audio applications are putting your active track on the same core as the background kernel processes.
I’ve created a couple videos detailing my steps, this being the latest with Mojave, the other video link is in its YouTube description. There I also reproduce it within High Sierra:
YouTube
Here are the steps if you don’t want to watch the video. I use Logic Pro to demonstrate it since its CPU meter isn’t averaged like in Ableton 10 or Cubase 9.5.3. It’s easier to see the cpu spike. I have tested Ableton and Cubase and can reproduce the overload events.
1. Open Logic
2. Create Instrument Track with Alchemy Bowed Metal Space patch (or some other cpu intensive plugin) I usually add in a default chromaverb fx to get the cpu on live play over 50%. I’ve also used Keyscape, Kontakt libraries, and uh-e synths with similar results.
3. Double click your Logic CPU meter to get floating window showing all cores.
3. Open your OSX Console App and search Battery and note the time the AppleSmartBatteryManager start poll event occurs.
4. Open your System Pref Time and Date leave that viewable to track time.
5. Start playing the Alchemy patch live as the active track and watch CPU meter as time approaches the AppleSmartBatteryManager poll start.
6. You should encounter a sizable cpu spike, and high potential for a audio drop out. Repeat a few more min cycles noting if you got a glitch audio dropout.
7. Return to the System Console and search those event times. You should see the AppleSmartBatteryManager poll start, then immediately restart, then some of its command checks, and if you had a dropout, a CoreAudio overload message(s). All occurring at the same second mark.
On my tested systems I get a CoreAudio overload event more than 90% of the time. And register a CPU spike every time. I’ve tested with the internal MBP sound, and RME Babyface Pro, and a Digigrid D Ethernet Audio Interface. Depending on project size this can occur at all CoreAudio buffer settings. My example above I had 128 selected. Changing the processing core setting in Logic has no effect. It always puts the active track the same as the kernel level processes.
I’ve started a bug report through Apple developer for Mojave. But as with all things, the more eyes that get on this the more likely a fix.