# coreaudiod High CPU on Mac: Check Apps, Devices and Drivers

> Trace coreaudiod CPU load with controlled app and device tests, check aggregate audio settings, and remove drivers only with a known owner and recovery path.

Published: 2026-05-17 | Updated: 2026-10-31

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](https://support.apple.com/guide/activity-monitor/view-information-about-processes-actmntr1001/mac) 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](https://mole.fit/blog/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](https://rogueamoeba.com/support/manuals/loopback/?page=devicebasics)
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](https://existential.audio/blackhole/support/). 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](https://support.apple.com/guide/audio-midi-setup/ams094c7edb4/3.6/mac/26)
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](https://github.com/ExistentialAudio/BlackHole/wiki/Uninstallation)
identify its driver bundles in this directory:

```text
/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](https://rogueamoeba.com/support/manuals/loopback/?page=etc-installinguninstalling)
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](https://mole.fit/blog/how-to-uninstall-zoom-teams-mac) and the
tested guides for [Loopback](https://mole.fit/tested-apps/loopback), [Zoom](https://mole.fit/tested-apps/zoom) and [Teams](https://mole.fit/tested-apps/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.

---

Canonical HTML page: https://mole.fit/blog/coreaudiod-high-cpu-mac
Blog index for agents: https://mole.fit/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt