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.