FIX: sustained 12-15% coreaudiod CPU usage on M1-* (possibly intel too)

[throAU]

If you've ported your user profile from Mac to Mac over several years, as I have, you may have noticed coreaudiod using a heap of CPU when not playing audio. Essentially once it starts the daemon, it constantly uses 12-15% CPU. THis may impact battery life, performance, etc. Likely 12-15% because it is 100% of a single core.

If this is the case, you may be missing the folder

• ~/Library/Preferences/Audio

from your user account. This folder is apparently created on user creation on new users, but if your user account is 15 years old like mine (or maybe nowhere near that old, but ported from another machine), it may not be there. It is used to store audio coreaudiod preferences for your user account (somehow/something).

This causes coreaudiod to freak out somewhat and hang on 12-15% CPU consumption constantly once it starts (e.g., you play some sound, fire up zoom, etc. it stays on 12-15% until you reboot).

Fix?

Verify whether or not that folder exists, and if not, open a terminal window and type:

• mkdir ~/Library/Preferences/Audio
• sudo chown _coreaudiod:admin ~/Library/Preferences/Audio

edit: confirmed the chown line is required for the problem to be resolved

And reboot. You should now notice coreaudiod is not constantly high up in activity monitor! In fact, if not playing/recording audio it shouldn't even be running!


edit:
This can not have been good for battery life, and may be why some people are seeing much worse than expected on the new machines.

 

[yitwail]

If you've ported your user profile from Mac to Mac over several years, as I have, you may have noticed coreaudiod using a heap of CPU when not playing audio. Essentially once it starts the daemon, it constantly uses 12-15% CPU. THis may impact battery life, performance, etc. Likely 12-15% because it is 100% of a single core.

If this is the case, you may be missing the folder

• ~/Library/Preferences/Audio

from your user account. This folder is apparently created on user creation on new users, but if your user account is 15 years old like mine (or maybe nowhere near that old, but ported from another machine), it may not be there. It is used to store audio coreaudiod preferences for your user account (somehow/something).

This causes coreaudiod to freak out somewhat and hang on 12-15% CPU consumption constantly once it starts (e.g., you play some sound, fire up zoom, etc. it stays on 12-15% until you reboot).

Fix?

Verify whether or not that folder exists, and if not, open a terminal window and type:

• mkdir ~/Library/Preferences/Audio
• sudo chown _coreaudiod:admin ~/Library/Preferences/Audio

edit: confirmed the chown line is required for the problem to be resolved

And reboot. You should now notice coreaudiod is not constantly high up in activity monitor! In fact, if not playing/recording audio it shouldn't even be running!


edit:
This can not have been good for battery life, and may be why some people are seeing much worse than expected on the new machines.

That's very interesting. I don't have the directory you mention, but coreaudiod is only 0.4% CPU, unless I play something in Music app, and then it increases to 7-8%, but as soon as I pause the song, it drops back down to 0.4%
FYI, this is on a M1 MBA running Big Sur. Anyway, I'm not inclined to do anything about it at the moment, since I believe it's just 0.4% of one CPU core.

 

[throAU]

That's very interesting. I don't have the directory you mention, but coreaudiod is only 0.4% CPU, unless I play something in Music app, and then it increases to 7-8%, but as soon as I pause the song, it drops back down to 0.4%
FYI, this is on a M1 MBA running Big Sur. Anyway, I'm not inclined to do anything about it at the moment, since I believe it's just 0.4% of one CPU core.

Yeah sounds like you're not impacted the same way. If you're only seeing 0.4% definitely not the same issue.

For what its worth I found this fix somewhere else on reddit I think.

Mine was definitely hitting 12% or so and staying at 12%+ usage after playing audio until reboot (or coreaudiod was killed). After the above, coreaudiod is not running unless playing audio (which I presume is "expected" behaviour)

I've only noticed this problem on the M1-Pro running Monterey. So it's possible it's a Monterey thing (but can't confirm as that's the earliest OS the M1-Pro 14" runs).

 

[mr_roboto]

I have a M1 Max running Monterey (12.1) with a really old user account that's been migrated across at least 10 years worth of computers and macOS versions. I do not have the ~/Library/Preferences/Audio directory, but I also do not have coreaudiod consuming lots of CPU. It hovers around 0% while no sound is playing, goes up to about 10% of one CPU while sound is playing, and returns back to near-zero soon after all sounds stop.

 

[jdb8167]

I have a M1 Max running Monterey (12.1) with a really old user account that's been migrated across at least 10 years worth of computers and macOS versions. I do not have the ~/Library/Preferences/Audio directory, but I also do not have coreaudiod consuming lots of CPU. It hovers around 0% while no sound is playing, goes up to about 10% of one CPU while sound is playing, and returns back to near-zero soon after all sounds stop.

It’s possible that the user ~/Library/Preferences/Audio is a fallback. It is unusual to have user preferences file not owned by the user I think. Maybe the problem only happens if all the potential directories are missing.

 

[jdb8167]

Now that I'm in front of my Mac, I'm thinking my guess is correct since there is a /Library/Preferences/Audio directory owned by system and group _coreaudiod. I also do not have anything at ~/Library/Preferences/Audio.

@throAU can you check if /Library/Preferences/Audio exists on your system?

 

[throAU]

Now that I'm in front of my Mac, I'm thinking my guess is correct since there is a /Library/Preferences/Audio directory owned by system and group _coreaudiod. I also do not have anything at ~/Library/Preferences/Audio.

@throAU can you check if /Library/Preferences/Audio exists on your system?

I have one but permissions are as follows:

% cd /Library/Preferences
% ls -la | grep Audio
drwxrwxr-x 5 root _coreaudiod 160 14 Dec 18:11 Audio

owned by root - does that match what you have? When you say system do you mean an account actually called system, or root? I don't have a user called system on my box... I do have a group in /etc/group called "sys"...

 

[mr_roboto]

I have one but permissions are as follows:

% cd /Library/Preferences
% ls -la | grep Audio
drwxrwxr-x 5 root _coreaudiod 160 14 Dec 18:11 Audio

owned by root - does that match what you have? When you say system do you mean an account actually called system, or root? I don't have a user called system on my box... I do have a group in /etc/group called "sys"...

I have:

% ls -al /Library/Preferences | grep Audio
drwxrwxr-x   5 root         _coreaudiod    160 Jan 17 13:57 Audio/

After creating ~/Library/Preferences/Audio, did the system actually populate it with anything? I'm wondering if this was actually responsible for fixing your problem, or if it was just a temporary condition cleared up by a reboot.

 

[throAU]

After creating ~/Library/Preferences/Audio, did the system actually populate it with anything? I'm wondering if this was actually responsible for fixing your problem, or if it was just a temporary condition cleared up by a reboot.

Yeah, it dumped some stuff in there:

root# cd ~jrose/Library/Audio/ root# ls -la total 16 drwx------+ 6 _coreaudiod admin 192 May 3 2021 . drwx------@ 101 jrose staff 3232 Nov 29 05:59 .. -rw-r--r--@ 1 jrose staff 6148 Dec 21 12:18 .DS_Store drwx------+ 2 jrose staff 64 Apr 9 2020 MIDI Drivers drwx------+ 6 jrose staff 192 May 3 2021 Plug-Ins drwx------+ 4 jrose staff 128 Apr 9 2020 Sounds


This isn't something that was happening for one reboot. It had been reliably happening for the past couple of months at least that I noticed.

What's weird is that if the Audio folder is not owned by _coreaudiod, I go back to seeing 12% CPU consumption permanently, yet all the files that populated the folder are owned by my user account. What's also weird is the dates on those files. either they're copied and the dates came across or they're hard links or something?

I am tempted to do a clean install at some point. There's some audio driver from immersedVR that came across from my time machine backup that I'd like to be rid of given I haven't had the app installed for 18 months.

 

[mr_roboto]

I've been thinking about doing a clean install at some point, but keep putting it off. The procrastination has been going on for many years at this point. I think I started this user account shortly after the beginning of the Intel Mac era, but it might even go back to PowerPC...

 

[jdb8167]

I have one but permissions are as follows:

% cd /Library/Preferences
% ls -la | grep Audio
drwxrwxr-x 5 root _coreaudiod 160 14 Dec 18:11 Audio

owned by root - does that match what you have? When you say system do you mean an account actually called system, or root? I don't have a user called system on my box... I do have a group in /etc/group called "sys"...

Yes. the user system is the Finders way of displaying the root user. Sorry for the confusion.

 

[dimitarvp]

This kind of helped. CPU dropped from 5% sustained to about 3.4% but that's not a big improvement. I've seen StackOverflow threads where certain apps have to be denied access to microphone if they constantly poll microphone in the background but right now can't be bothered. What's even more worrying, I can't find Chrome's old option to stop listening for "OK, Google".

 

[throAU]

I'll note that this issue was fixed permanently for me with either the macOS update that came out after this post - OR an update to Zoom.

I believe Zoom was triggering it to be honest, but either way I am running the same machine with Zoom now and don't see this behaviour any more.

 

[Berlinsky]

If you've ported your user profile from Mac to Mac over several years, as I have, you may have noticed coreaudiod using a heap of CPU when not playing audio. Essentially once it starts the daemon, it constantly uses 12-15% CPU. THis may impact battery life, performance, etc. Likely 12-15% because it is 100% of a single core.

If this is the case, you may be missing the folder

• ~/Library/Preferences/Audio

from your user account. This folder is apparently created on user creation on new users, but if your user account is 15 years old like mine (or maybe nowhere near that old, but ported from another machine), it may not be there. It is used to store audio coreaudiod preferences for your user account (somehow/something).

This causes coreaudiod to freak out somewhat and hang on 12-15% CPU consumption constantly once it starts (e.g., you play some sound, fire up zoom, etc. it stays on 12-15% until you reboot).

Fix?

Verify whether or not that folder exists, and if not, open a terminal window and type:

• mkdir ~/Library/Preferences/Audio
• sudo chown _coreaudiod:admin ~/Library/Preferences/Audio

edit: confirmed the chown line is required for the problem to be resolved

And reboot. You should now notice coreaudiod is not constantly high up in activity monitor! In fact, if not playing/recording audio it shouldn't even be running!


edit:
This can not have been good for battery life, and may be why some people are seeing much worse than expected on the new machines.

Yepp, this fix worked for me on an Intel 2018 Quad Core MacBook Pro running 12.4 after migrating from Mojave, Thanks so much!

 

[dimitarvp]

Actually mine's back at 5% CPU at all times when idle, and 15% when playing music (iMac Pro so Intel CPU).

The partial "fix" was hilarious. Unplug the headphones -- that are using a normal 3.5mm jack and _not_ USB -- and re-plug them.

However, now, with music or not, `coreaudiod` is firmly stuck at 5% CPU no matter what I do. Stopped every single app that has access to the microphone as people suggested in other forums like StackOverflow -- zero effect. Maybe a restart could help but I lately did it for the recent macOS update and didn't do anything, so I doubt it.

The original solution didn't do almost anything for me -- the CPU usage dropped slightly for a few hours then it got back to 5%. I am at a loss. If anyone has any other wild ideas what to do I'd be open to try them likely, lol.

Forgot to say: I use the SoundSource app so I can redirect sound from separate apps to different sound outputs (e.g. I only ever want Zoom to use my headphones but Firefox must always use the speakers). I know that many apps allow you to change their input/output devices but I also want to individually control the volume of each app so there's that as well. Maybe that is the culprit but even if it is, I don't want to stop using the app. ?

 

[eicca]

My coreaudiod got stuck around 7%. I implemented the fix above as I did not have the mentioned folder present. Rebooted and back to 0% at idle.

We'll see if this sticks.

Between this, the random freezing of the Dock process, and the constant memory leaks from Finder and windowserver, and I'm sure much more, I'm kind of appalled by Monterey. How I wish Mojave would run on these things. That was the most stable macOS I've ever used.

 

[throAU]

The problem has returned for me, and the original fix doesn't work....

🤬

 

[JtheLemur]

Lol, gonna bump this up. I just noticed that playing audio with Music.app, coreaudiod uses between 16-19% CPU.

That's fscking insane. That is absolutely balls to the wall insanity. There is no reason coreaudiod should be doing this simply playing music.

Literally nothing else running to cause the issue, and of course pausing the music drops CPU usage down to 0%.

Anyone find a consistent fix for this dummy high CPU usage?

EDIT: What's insane is, Electron crap like Discord and Slack are chilling at a combined 4%, which is embarrassing. These are supposed to be the CPU hogs. -_-

 

[mr_roboto]

Can you tell if coreaudiod is running on an efficiency core? On Apple Silicon, sometimes very light loads look like they're running a high CPU % because the process is on an efficiency core clocked well below its peak frequency. Side effect of Apple getting really good at using very little power to execute background tasks, and audio mixing is a prime candidate for that kind of thing.

 

[jont-fu]

I had this issue and what's weird is that my user account is not old, because I specifically made a fresh account for my M1 Pro machine. But there was no ~/Library/Preferences/Audio folder in my home directory, only in the root directory. So far I'm not sure if it was just the reboot that helped.

 

[rmbarcelo]

Just followed the instructions by creating the directory and the sudo chown...
I also updated to Ventura 13.3.1. I'm on Macbook Air 2018. Coreaudio went from 30-35% down to 0.6%.
Not sure what helped, but thanks!

 

[throAU]

This kind of helped. CPU dropped from 5% sustained to about 3.4% but that's not a big improvement. I've seen StackOverflow threads where certain apps have to be denied access to microphone if they constantly poll microphone in the background but right now can't be bothered. What's even more worrying, I can't find Chrome's old option to stop listening for "OK, Google".

So... update.

Noticed I have been having this problem again - this time on Sonoma.

Turns out this is a thing. I discovered that Microsoft Remote Desktop was using core audio for monitor the microphone constantly. Denied it access to the mic and no more coreaudiod running.


This is maybe more likely the root cause - apps constantly listening on the mic, which means they need core audio to process input constantly.

The file/folder thing may or may not have any impact; however the folder I mentioned in the OP was present with correct ownership and I was still having the problem until removing MS remote desktop's access to the microphone above.

 

[mikeshep]

Have this exact problem…On Mojave. 2018 Mini. Can’t get the Terminal command to “populate” the newly created Audio folder with the coreaudiod data. coreaudiod is located in the System Folder Audio folder. I followed all the sudos to the letter. The User directory had no Audio Folder. I assign it Read/Write permissions… Core Audio is only read from that System Audio Folder. My studio’s devices are all seeing Core Audio… but i’m running at a continuous, sustained 80% CoreAudio CPU usage! And yes i also migrated from an older Mac when i transitioned to this one a year or so ago. I’m stumped. Fan is kicking in frequently as well. No devices are on, nothing seems to be running in background…all other processes except “Launchd” are at nominal to zero CPU usage.

Hoping someone might be able to help pinpoint what I’m overlooking. Reinstalling the OS did nothing btw.

It’s as if, the location in the System Audio Folder is wrong and coreaudiod should be in the user folder instead…
and for whatever reason its getting “pinged” continuously… toggling off apps that want access to audio in Privacy control panel had no effect … Any ideas much appreciated!

 

[highmayhem]

Looking at the OP, he in fact does reference

~/Library/Preferences/Audio

and not

/Library/Preferences/Audio

...
It’s as if, the location in the System Audio Folder is wrong and coreaudiod should be in the user folder instead…
and for whatever reason its getting “pinged” continuously… toggling off apps that want access to audio in Privacy control panel had no effect … Any ideas much appreciated!

 

[Celeri]

I had a similar issue on my M1 MacBook Air: constant 5-10% of CPU used by 'coreaudiod' and even prevented the machine to sleep correctly (the process was listed in the "PreventUserIdleSystemSleep" category in the "pmset -g assertions" output.

I had already tried the "Audio" folder trick, but without any effect. But today I followed @dimitarvp's suggestion regarding SoundSource, of which I had an old version installed without using it anymore... I uninstalled it with AppCleaner, then rebooted, and now 'coreaudiod' is not even listed in the Activity Monitor anymore.

Looking good so far!