coreaudiod High CPU on Mac: Check Apps, Devices and Drivers
When coreaudiod stays near the top of the CPU list, start with the apps and devices using audio. It is macOS's Core Audio daemon, not an app you need to uninstall. Restarting it can reset audio temporarily, but does not tell you which app, device or driver caused the load.
Audio activity during music playback, calls or routing through several devices is not by itself evidence of a fault. Sustained high CPU after those activities stop deserves a controlled comparison, rather than a universal percentage that declares the process healthy.
Find the App That Changes the Load
Apple's Activity Monitor instructions explain process search and sorting by a column. Find coreaudiod, watch CPU usage, and keep the same observation conditions while testing one app at a time.
Pause music and browser video, finish any call or recording, then quit the relevant apps one by one. Include Zoom or Teams if they were running. Reopen the suspected app and repeat the same playback or call test. A repeatable fall and rise narrows the trigger; CPU usage alone does not identify the audio client or prove that the app is defective.
| Comparison | What it helps separate | Next check |
|---|---|---|
| Playback or call running, then stopped | Active work versus continuing activity | Quit that app and test again |
| Built-in output versus an external or virtual device | Device or routing involvement | Reconnect one device at a time |
| Simple route versus an aggregate device | Combined-device configuration | Review rates and synchronization |
For other background processes, use Mac processes explained. Do not apply a different daemon's reset steps to the audio service.
Reduce the Route Before Removing Anything
Record the current input and output choices in the apps you use. For a short test, select built-in audio where available and disconnect unnecessary external audio devices after stopping playback. Repeat the same workload, then restore the previous route to compare.
Virtual devices need their own check. Loopback's manual explains that its devices persist even when the app is closed, and can be disabled and enabled again. Quit alone is therefore not a test that removes Loopback from the route. Disable the relevant virtual device for the comparison, recording its routing first.
BlackHole also provides virtual routing, including aggregate and multi-output setups in its support instructions. Their presence is a reason to inspect the route, not proof that either product causes high CPU.
Check Rates and Aggregate Devices
Open Audio MIDI Setup and inspect the device used by the affected app. Before changing anything, record its rate and any aggregate-device members, clock source and synchronization settings so that you can restore them.
For macOS Tahoe 26, Apple's aggregate-device guidance calls for matching sample rates and drift correction where devices are not synchronized in hardware. Follow the guidance for that configuration, rather than selecting the highest rate or toggling every synchronization option. A mismatch is a configuration to investigate, not a confirmed explanation for every CPU spike.
First compare with a single device. If the aggregate route is still needed, change only the identified setting, repeat playback and a microphone test, and compare CPU again. If sound becomes worse or a required route stops working, restore the recorded settings.
Remove a Driver Only When Its Owner Is Known
The BlackHole uninstall instructions identify its driver bundles in this directory:
/Library/Audio/Plug-Ins/HAL
This is not a cache directory to empty. Only remove a specific third-party driver when you know which app installed it and have its removal instructions and a reinstall path. Use BlackHole's supplied uninstaller for the matching variant where possible. For Loopback, use its built-in uninstall flow to remove devices and backend components rather than guessing at shared engine files.
Keep routing notes before uninstalling. Test playback and microphone input afterward, and use the vendor's installer if the removed device is needed again. For app removal, see Zoom and Teams uninstall guidance and the tested guides for Loopback, Zoom and Teams.
Treat a Core Audio Restart as a Reset
BlackHole's manual removal flow restarts Core Audio after removing its driver. That is a
specific installation step, not evidence that repeatedly killing coreaudiod fixes high CPU.
The reset interrupts audio, so finish calls and recordings before any vendor-directed reset.
After a reset or restart, repeat the same app and device test. If the load returns with the same route, record that combination and contact the app or device vendor. A temporary quiet period does not establish that the underlying cause is gone.
Where Mole Fits
Mole Mac's Status process list shows CPU usage, useful for comparing app activity. Its Software uninstall scan can offer verified app-owned HAL driver remnants for review, including a specific Zoom driver rule; it does not offer every file in HAL for deletion. Mole protects Core Audio system state and does not provide a Core Audio reset operation.
FAQ
Is High coreaudiod CPU Always a Problem?
No fixed percentage establishes that. Compare the same audio work with apps stopped and with a simpler route, and investigate load that persists or accompanies broken audio.
Can I Delete Everything in HAL?
No. Identify the owning app and follow its vendor's removal steps for the specific driver. Keep a reinstall path and your routing notes before making that change.
Why Does High CPU Return After Killing coreaudiod?
A reset does not remove the app, route or driver that triggered the activity. Reproduce with one app and one device at a time, instead of repeating resets during active audio work.