What Is coreaudiod on Mac? 268 Audio Contexts in a Week

coreaudiod is the macOS Core Audio server. Every app that plays or records sound talks to it, and it is the process that actually drives your speakers, headphones and microphones. On my Mac mini it has been running for 25 days and has used 58 minutes 34 seconds of CPU in that time. That is about 0.16% of one core, and it sits at number 28 of 681 processes. In eleven top samples taken while nothing was playing it read 0.0% every time. If coreaudiod is at the top of your Activity Monitor, it is almost always doing work for some other app.

I learned that the embarrassing way. While I was measuring for this post I found a process at 100% CPU. It was not coreaudiod. It was a copy of Betaflight I had started the evening before to test Betaflight on Mac and never quit, and it had burned 804 minutes of CPU in 18 hours. When I killed it, the power log showed coreaudiod releasing four audio "contexts" with sleep-blocking assertions. They had been held for 17:59:25. The app had never played a sound, and the assertions were logged under coreaudiod's name, not Betaflight's.

The rig is a headless Mac16,10 (M4, 16 GB) on macOS 26.4.1, up 25 days. Its only audio device is the built-in speaker. I measured on 2026-10-23 as an admin user, without sudo.

What coreaudiod is

$ ps -axo pid,user,etime,time,command | grep [c]oreaudiod
  669 _coreaudiod  25-01:50:06  58:33.98 /usr/sbin/coreaudiod

$ man coreaudiod
     coreaudiod is a daemon used for Core Audio related purposes.  coreaudiod
     was introduced with OSX version 10.4.

That is the whole man page, dated 2004. The binary is 530,512 bytes and universal (x86_64 and arm64e). It runs as a system-wide LaunchDaemon, /System/Library/LaunchDaemons/com.apple.audio.coreaudiod.plist, under its own user _coreaudiod, not as you and not as root. If that split is unfamiliar, LaunchAgent vs LaunchDaemon explains it. The plist has no KeepAlive key. Instead it registers five Mach services, including com.apple.audio.audiohald (the Hardware Abstraction Layer, the part apps call to reach a device) and com.apple.audio.coreaudiod. launchd starts it whenever something asks for one of those. It is also marked POSIXSpawnType Interactive, the foreground scheduling class, because late audio glitches.

coreaudiod is the hub of a small family. On this Mac:

Process	Runs as	CPU in 25 days	Role
coreaudiod	_coreaudiod	58:33.98	Audio server, loads device drivers
audioclocksyncd	root	22:50.21	Clock sync between audio devices
audioanalyticsd	root	1:04.39	Audio telemetry
audiomxd	_audiomxd	0:01.20	Audio mixing and routing service
usbaudiod	_coreaudiod	0:00.37	USB audio class driver host
Core Audio Driver (ParrotAudioPlugin.driver)	_coreaudiod	0:00.02	Out-of-process driver plug-in

The drivers it loads, and one that looks third-party

coreaudiod does not know about devices by itself. It loads driver bundles called Audio Server Plug-ins. Apple's ships 12 in /System/Library/Audio/Plug-Ins/HAL: AirPlay, Bluetooth, AVB, virtio sound, Continuity camera audio, hearing devices and the built-in hardware. Third-party drivers go one folder up. Apple's own sample tells developers to "Install the sample's .driver bundle to /Library/Audio/Plug-Ins/HAL and reboot your computer." That folder is where virtual devices from loopback tools, meeting apps and room-correction software live, and it is the first place to look when coreaudiod misbehaves.

Mine has one item in it, ParrotAudioPlugin.driver. I had never installed anything by that name, so I checked before assuming:

$ plutil -p /Library/Audio/Plug-Ins/HAL/ParrotAudioPlugin.driver/Contents/Info.plist | grep Identifier
  "CFBundleIdentifier" => "com.apple.audio.ParrotAudioPlugin"
$ codesign -dv /Library/Audio/Plug-Ins/HAL/ParrotAudioPlugin.driver 2>&1 | grep Platform
Platform identifier=26
$ pkgutil --file-info /Library/Audio/Plug-Ins/HAL/ParrotAudioPlugin.driver | grep pkgid
pkgid: com.apple.files.data-template

It is Apple's. It came with the macOS 26.4.1 data template and has a platform signature. It runs as its own small process and has used 0.02 seconds of CPU. So the rule is: read the bundle ID and signature before you delete anything from that folder. codesign on Mac covers reading signatures.

Who used coreaudiod on a Mac that plays nothing

When an app opens an audio stream, coreaudiod creates a numbered "context" for it. While the context is active, coreaudiod takes power assertions with names like com.apple.audio.context4410.preventuseridlesleep, which keep the Mac from idle-sleeping. These are logged under coreaudiod's PID, not the app's. I first ran into this in what's keeping your Mac awake: coreaudiod owned 70% of all assertion events in that week. At the time I could not say why. This time I could, because pmset -g log records how long each assertion was held, and log show keeps enough coreaudiod history to match them to a cause.

The power log covered 2026-10-16 13:49 to 2026-10-23 13:44. In that week coreaudiod released assertions for 268 distinct contexts. They fall into four groups:

Group	When	Contexts	Held
macOS, on a timer	02:38, 08:38, 14:38, 20:38 every day	4 per burst	1:15 to 1:30
Not traced	released 17:39 every day	4 per day	24:00:02 to 24:00:04
Apps I launched for tests	during test sessions	4 to 12 per launch	12 s to 4:48
Forgotten Betaflight	10/22 19:34 to 10/23 13:33	4	17:59:25

I traced the 02:37 burst to a source. At 02:37:13 SoftwareUpdateNotificationManager refreshed after a background update scan. In the same second nsattributedstringagent, the helper that turns HTML into styled text, launched a WebKit GPU process. runningboardd logged that process as com.apple.WebKit.GPU with host pid 3813, the agent. coreaudiod then logged four AllowNegotiateAdaptInSetComposition lines, one for each new context. Ninety seconds later the four contexts were released. So the chain is: rendering a piece of text through WebKit set up audio, and nothing was played. I traced only that one burst. The other six-hourly bursts have the same shape (four contexts, about 90 seconds), but I have not confirmed that each comes from the same chain. The daily 17:39 group I cannot explain. The log says each of those four contexts was held for exactly 24 hours, yet pmset -g assertions at 13:44 listed no coreaudiod assertion at all. The 17:39 release on 10/22 fell before the start of the unified log I still had.

The Betaflight case fits the same pattern. Its 2026.6 Mac build is a Tauri app, and Tauri draws its UI with the system WebKit. It held its four contexts for as long as it ran.

What a silent stream costs

To see the cost of one stream by itself, I wrote 40 seconds of digital silence to a WAV file and played it with the volume set to zero:

$ afplay -v 0 silence.wav &
$ top -l 11 -s 2 -pid 669 -stats pid,command,cpu
# before: 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
# during: 0.0 3.7 3.4 3.4 3.4 3.4 3.4 3.4 3.5 3.4 3.4

$ pmset -g assertions | grep -A1 coreaudiod
   pid 669(coreaudiod): PreventUserIdleSystemSleep named: "com.apple.audio.BuiltInSpeakerDevice.context.preventuseridlesleep"
	Resources: audio-out BuiltInSpeakerDevice

Volume zero is not "off". coreaudiod still started I/O on the speaker, ran the DSP chain at a steady 3.4% of a core, and held a sleep assertion for 41.2 seconds for a 40-second file. The log shows the assertion taken at 13:41:00.620 and released at 13:41:41.831, after the speaker returned to idle. afplay itself used 0.09 seconds. The audio server did the work and was also the one recorded as keeping the Mac awake.

Only streams that actually start device I/O cost CPU like that. Most of the 268 contexts never started the speaker: in the roughly 18 hours of coreaudiod log that the unified log still held, the speaker started only three times. Two were QGroundControl starting up at 10:52 and 10:53 during my Mission Planner on Mac tests (4.1 s and 2.0 s), and the third was my silent file. That is why an idle Mac shows coreaudiod at 0.0% even though it is creating contexts all day.

When coreaudiod really does pin a core

The reports that matter are the ones where it sits at 100% with nothing playing. I read three Apple Community threads and one vendor knowledge-base article:

• coreaudiod and locationd over 150% on Sequoia 15.4 (M3 Pro, March 2025). Two posters traced it to "Recording Indicator Utility", a third-party tool that hides the orange microphone dot, used alongside Boom 3D's virtual microphone. One poster saw the problem only in their own account, not a fresh one.
• coreaudiod running at 100% CPU (M1 MacBook Air, 15.5, June 2025). It started at login for one user. Killing it only restarted it. After clearing unknown Safari website data and rebooting, the poster saw 7 seconds of CPU in several hours, but did not call it fixed.
• coreaudiod looping on M1 MacBook Air (December 2025). About 100% of a core "while doing nothing". It also restarted when killed and stopped only when the poster logged out of that account. A reply suggested removing audio items from Login Items.
• Sonarworks documents coreaudiod at about 100% CPU on macOS 10.14 and 10.15 with SoundID Reference 5.7.3, after it shipped an updated HAL driver. Its fix for those versions is "not planned".

Every cause someone found was another program: a HAL driver, a virtual mic, an audio app that opens at login, or something tied to one account. That matches what I measured. coreaudiod does the work, and some other process asks for it. Several cleaner-app guides blame a missing /Library/Preferences/Audio folder. On this Mac that folder exists and holds two plists and a Data folder. I have nothing that shows it going missing, so I can't support or rule out that claim.

Restarting it, and what I could not test

The usual advice is sudo killall coreaudiod. Without sudo, here is what happens:

$ killall coreaudiod
No matching processes belonging to you were found

$ launchctl kickstart -k system/com.apple.audio.coreaudiod
Could not kickstart service "com.apple.audio.coreaudiod": 150: Operation not permitted while System Integrity Protection is engaged

The first fails because the process belongs to _coreaudiod. The second is the other common recommendation. Without root it returns an error that mentions SIP. I did not run either command with sudo on this headless machine, so I can't say whether sudo gets past that message. Either way, a restart only resets coreaudiod. Because launchd starts it on demand, the next audio client brings it back, and the Apple Community posters saw the 100% return when the cause was still running.

Look for the client first:

# who is holding audio right now (the Resources line names the device)
pmset -g assertions | grep -A1 coreaudiod

# how long each context was held in the last week (look for hours, not seconds)
pmset -g log | grep 'coreaudiod) Released' | grep -v '00:0[0-9]:'

# third-party drivers coreaudiod loads (check bundle IDs before removing anything)
ls /Library/Audio/Plug-Ins/HAL

# when the speaker actually started, so you can match it to an app launch
log show --last 1h --predicate 'process == "coreaudiod" AND eventMessage CONTAINS "IOWorkLoopInit"'

The second command is the one that would have caught my Betaflight copy: a hold of 17:59:25 stands out against 1:30. On my Mac it also lists the daily 24-hour group, so expect some lines you can't explain. If you run log show from zsh, read the notes in the log show command first, because zsh has a builtin called log. For a neighbour that also gets blamed for other people's work, see what avconferenced is.

FAQ

What is coreaudiod on Mac?

coreaudiod is the macOS Core Audio server. It is a system LaunchDaemon that runs as the _coreaudiod user, loads audio driver plug-ins from /System/Library/Audio/Plug-Ins/HAL and /Library/Audio/Plug-Ins/HAL, and mixes and sends every app's audio to the speakers, headphones or interfaces. Apps never drive the hardware themselves; they open streams in coreaudiod. When idle it normally uses 0% CPU.

Is it safe to kill coreaudiod?

Yes, in the sense that nothing is lost. Audio stops for a moment and launchd starts coreaudiod again the next time an app asks for audio. It needs sudo because it runs as the _coreaudiod user. Killing it does not fix high CPU caused by another app, a third-party driver in /Library/Audio/Plug-Ins/HAL or a login item; the load comes back when that client reconnects.

Why does coreaudiod keep my Mac awake when nothing is playing?

coreaudiod takes PreventUserIdleSystemSleep assertions on behalf of the apps that open audio streams, so the power log lists coreaudiod rather than the app. A stream counts even at volume zero, and some apps, including WebKit-based ones, open audio contexts without playing anything. Run pmset -g log and look for coreaudiod "Released" lines with long hold times to find the app.

Measured on 2026-10-23 on one headless Mac mini (Mac16,10, M4, 16 GB, macOS 26.4.1, up 25 days, built-in speaker only), as an admin user without sudo. Process and CPU figures come from ps and top; driver details from plutil, codesign and pkgutil; the 268-context census from one pmset -g log read covering 2026-10-16 13:49 to 2026-10-23 13:44, grouped by release time and hold duration. The 02:37 attribution comes from matching coreaudiod, runningboardd and SoftwareUpdateNotificationManager entries in /usr/bin/log show to the same second. Only that burst was traced, and the unified log held about 18 hours of coreaudiod history. The silent-stream test was one 40-second afplay run at volume 0. I did not run anything with sudo, so the kill and kickstart results are non-root results only. User reports come from three Apple Community threads, read in full, and one Sonarworks knowledge-base article; the plug-in folder is from Apple's driver sample documentation. The Betaflight process was my own test leftover from the previous day, and I killed it while writing this.