coreaudiod at 112% CPU: the sample-rate mismatch that froze Zoom on my Mac

I'm Hisashi. I've run my own company for 22 years, and from 2011 to 2023 I ran it while moving between countries. My work means a lot of Zoom calls, and it also means my main Mac is permanently mid-recording, mid-stream, or mid-long-running-job. Rebooting is never an option I accept without a fight.

So when Zoom started freezing on launch (spinning, audio dead, the whole machine feeling sticky), I did what I always do: found the actual culprit instead of power-cycling my way past it. The culprit turned out to be embarrassingly small. One audio device was set to 44.1kHz while everything else on the system ran at 48kHz. That single mismatch had macOS's audio daemon burning a full CPU core, continuously, for weeks.

If your Mac's audio feels haunted (Zoom slow to join, recording apps erroring out, UI hitching when sound plays), there's a decent chance you have the same disease. Here's the full diagnosis and the fix. Total time: about 15 minutes. Reboots required: zero.

The symptom

Clicking a Zoom link did nothing for a long time. The meeting window eventually appeared, but audio took even longer, and sometimes the app just sat there. Meanwhile the machine felt subtly wrong: keystrokes lagging, fans occasionally spinning up with nothing visible running.

top told the real story:

PID    %CPU  COMMAND
620    112.3 coreaudiod

coreaudiod is the macOS audio daemon (the process behind Core Audio; every app that plays or records sound talks to it). It should idle near 0%. Mine was pinned above 100%, meaning it had more than one full core to itself.

One more detail made it clear this wasn't a fresh problem. The process had accumulated over 39 hours of CPU time. This thing had been quietly cooking for weeks, and Zoom's launch sequence just made it visible, because Zoom enumerates and opens audio devices aggressively at startup, right into the teeth of a daemon that was already drowning.

Rule one: don't reboot

A reboot would have "fixed" this. It also would have destroyed the diagnosis, killed everything else the machine was doing, and guaranteed the problem came back next week.

macOS lets you restart a single system daemon:

sudo killall coreaudiod

launchd respawns it instantly. Audio drops for two or three seconds, then reconnects. That alone brought CPU back to normal. But that's treatment, not cure. If I stopped there, the daemon would start melting again the next time the trigger condition reappeared. So the real question: what makes coreaudiod spin?

The cause: one device at 44.1kHz

I'd seen this failure mode once before, with a Yamaha AG06MK2 mixer. The mixer was set to 44.1kHz, the Mac wanted 48kHz, and coreaudiod ground itself into paste doing sample-rate conversion on every audio callback. Unifying everything at 48kHz cured it permanently.

The AG06 wasn't even connected this time. But the pattern generalizes, so I dumped the nominal sample rate of every device on the system. You can do this in Audio MIDI Setup (the GUI way), but I wanted it scriptable, so I asked Core Audio directly. The check is a dozen lines of Swift using kAudioDevicePropertyNominalSampleRate:

MacBook Pro Microphone:  48000 Hz
MacBook Pro Speakers:    44100 Hz   <-- there it is
Microsoft Teams Audio:   48000 Hz
SWB Audio Capture:       48000 Hz
LoomAudioDevice:         48000 Hz
ZoomAudioDevice:         48000 Hz

The built-in speakers, of all things, had drifted to 44.1kHz. Everything else, including every virtual device, sat at 48kHz. Zoom negotiates 48kHz for calls.

Here's why that one line is expensive. When rates disagree, coreaudiod has to resample audio in real time between the mismatched clock domains, per stream, forever. Worse, apps that open devices at their preferred rate trigger renegotiation, and with a conferencing app in the mix you get a steady churn of format changes. Each one is cheap; a continuous stream of them, multiplied across every virtual device that mirrors system audio, is a full CPU core.

The fix is one property write (same API, AudioObjectSetPropertyData with 48000.0), or thirty seconds of clicking in Audio MIDI Setup. All devices at 48kHz, mismatch gone.

The aggravator: seven resident virtual audio drivers

While diagnosing, I looked at /Library/Audio/Plug-Ins/HAL/, the folder where apps install virtual audio devices. These are fake sound cards that apps use to capture or route system audio, and every one of them is a permanent client of coreaudiod, whether or not the app that installed it is running.

I had seven:

ARK.driver
LoomAudioDevice.driver
MSTeamsAudioDevice.driver
ParrotAudioPlugin.driver
SWBAudioCapturePlugIn.driver
TVRemoteAudio.driver
ZoomAudioDevice.driver

Seven virtual sound cards, resident 24/7. Each multiplies the cost of every device enumeration (which Zoom does at launch) and every format renegotiation (which the 44.1k mismatch was causing constantly). The mismatch lit the fire; this pile of drivers was the accelerant.

Some of these names tell you nothing, and this folder is a common hiding spot for abandoned software. Don't guess; verify. codesign tells you who actually shipped each one:

codesign -dv --verbose=2 /Library/Audio/Plug-Ins/HAL/TVRemoteAudio.driver

The census results:

• ARK.driver: Rogue Amoeba (the audio engine behind Loopback, Audio Hijack, SoundSource). Keeping it; I use their tools.
• LoomAudioDevice / ZoomAudioDevice / SWBAudioCapture: screen-recording and conferencing tools I actually use. Kept.
• ParrotAudioPlugin.driver: this one looked suspicious (unfamiliar name, sitting in a third-party folder), but the signature chain is Apple's own OS platform signing, not a Developer ID. It's a genuine macOS system component. Leave it alone; it would come back with the next OS update anyway.
• TVRemoteAudio.driver: TeamViewer's remote-audio driver. I use TeamViewer occasionally but never its audio streaming. Dead weight. Removed.
• MSTeamsAudioDevice.driver: Microsoft Teams. I only ever join Teams calls when someone else hosts one, and the browser version handles mic, camera, and screen share fine without installing anything. So I uninstalled the desktop app entirely. Note that uninstalling Teams leaves this driver behind; you have to delete it from the HAL folder yourself.

Two drivers gone (backed up first, always), then one more sudo killall coreaudiod to make the daemon reload its plugin list. Down to five residents, all accounted for.

Results

• coreaudiod: 112% CPU before, 0.4% after, and it stays there
• Zoom: clicking a meeting link now puts the window on screen in about 2 seconds
• Loom and other recording tools: device enumeration is lighter, so startup errors from enumeration timeouts should drop too
• Reboots: zero

Takeaways

• When a Mac feels sick, name the process before you touch anything. top -o cpu costs nothing. "Reboot it" is a diagnosis you pay for later.
• Audio weirdness on macOS (conferencing apps slow to join, recording apps failing, hitching when sound plays) should trigger one reflex: check that every device in Audio MIDI Setup shows the same sample rate. 48kHz is the sane default; one device at 44.1kHz can eat a core.
• System daemons can be restarted individually with sudo killall <daemon>. launchd brings them back in seconds. This solves a large class of "haunted Mac" problems without a reboot.
• Audit /Library/Audio/Plug-Ins/HAL/ once in a while. Every app you've ever installed for calls or screen recording may have left a virtual sound card there, and they all tax the audio daemon forever. codesign -dv identifies the vendor when the name doesn't.
• The accumulated CPU time column in ps is underrated. 39 hours on a daemon that should idle told me this was chronic, not acute, before I knew anything else.

The meta-lesson is the same one that I keep coming back to. A machine you depend on deserves root-cause fixes, not rituals. The reboot ritual works just often enough to stop people from ever learning what was actually wrong.