coreaudiod using too much cpu

Strange; my MacBook was performing fine, though I happened to notice that the CPU usage of the "coreaudiod" process was constant at about 10%.

There was plenty of idle, though it was enough of an irritant - especially since it had the highest cumulative CPU time of all processes - that I wanted to look into it.

(BTW: Nice concise man page for coreaudiod. :)

Interestingly, CPU usage dropped down under 2% as soon as I plugged in headphones, and jumped back up to 10% when I unplugged the headphones - very consistently, each time.

I profiled coreaudiod with Instruments (part of the Apple Developer Tools).

It was spending a lot of time in DspFuncHelper::process_IIR_xmm_LR(). The interesting symbols in the symbol stack under that: DspFuncEQ, IOAudioEngineUserClient, IOA_HWDevice, IOA_SingleDevice, IOA_Device, CAPThread.

I tried turning the iTunes EQ off. And then toggled it a few more times. No change. I tried quitting iTunes. Nothing I tried made a difference. I don't have any other audio apps (*) so I dropped it there.

There's some chatter online about it, though none seemed useful. (Mostly the standard voodoo of "Have you tried turning it off and on again?" (ref: The IT Crowd)

However there was one suggestion by a user named "bompi" in the Apple Discussions, to use launchctl to stop the process gracefully:

sudo launchctl stop com.apple.audio.coreaudiod

It automatically restarts - and even if you're listening to something at the time, there's only a very brief interruption.

I'd still like to figure out what happened, why, and how to prevent it, however this at least is a temporary fix.

*Correction: Obviously there are other apps that use audio, though no significant ones came to mind at the time. However, I do use Skype and that can obviously use audio - and I'd been conferencing about 12 hours earlier -- with some audio trouble (on my end only; the other side reported that it was fine). FWIW, it was Skype v5.0.0.7980 and I see that v5.0.0.7994 is available so I'll try that and see if that makes any difference...


Jim said...

"sudo killall coreaudiod" works fine too.

mvgfr said...

> "sudo killall coreaudiod" works fine too.

Yep - just more of a "sledgehammer". :)

Anonymous said...

As long as it's not a "kill −9" you're still being nice...

mvgfr said...

> As long as it's not a "kill −9" you're still being nice...

Presuming coreaudiod reacts properly to the signal - which it probably does.

I just prefer using the same system that brought it up, to take it down.

Anonymous said...

This is the most recent comment stream about this problem I can find easily online. I have the same issue. It is not a "just reboot" problem, as it apparently keeps coming back. (Unless you're used to a "must reboot daily OS type of OS"). The only advice I found was to clear all your audio preferences before rebooting. I have not yet tried this, but would be interested to know if it works and if so, what changed before and after reboot.
[Hard Drive -> Library -> Preferences -> Audio.]

Stuart R. Jefferys

mvgfr said...

I haven't seen the problem since then (and have changed computers a few times :) so I can't try that - though I appreciate the input!

Haytham Elkhoja said...

Hi, i have the same problem, i opened a question about it on Stack Exchange, none of the fixes mentioned above worked for me killing coreaudiod every now and then is NOT a fix :)


mvgfr said...

I agree; if you have to do it all the time, it's not a fix - luckily for me it was a transient issue and thus it was a viable workaround for me.

I say "was" because I don't see the problem anymore. I'm not sure what the change was, that made me not see the problem anymore; could have been software updates or new hardware.

FWIW: If it's just using 5% of CPU, I wouldn't be too worried about that - and it seems that would be, at worst, a *contributor* to heating the system up (and thus running fans higher) rather than the cause.

It may be the *proximal* cause (the straw that broke the camel's back), but I'd suggest looking for the *primary* causes (that made the camel's back ready-to-break).

Tom said...

It's the microphone noise canceling that causes it. (I don't know if that's what it's called. I use my OSX in Dutch).. Turn it off and the coreaudiod will settle when not playing any sound.

You're welcome ;)

mvgfr said...

> microphone noise canceling

very interesting indeed!

ppy said...

I'd like to confirm that microphone noise cancelling has nothing to do with this. It definitely seems to be a bug (or "feature") of lion.

The only possible lead I have found is that apparently coreaudiod is responsible for limiting the output volume dynamically when using internal speakers, in order to avoid permanent damage to the speakers themselves.

I am going to file this as a bug with apple, and suggest anyone else seeing the issue does the same (http://bugreport.apple.com)

Anonymous said...

They are quite important changes in Lion regarding the audio stack:
- up to now a system process called “coreaudiod” was used to handle system sounds and interact with “default” in/out devices.
- “coreaudiod” role has been enhanced a lot : it behaves now like a real sound server that access the audio streams to be sent and received by all running CoreAudio clients. So CoreAudio clients do not interact directly with the audio device driver anymore, but interact with “coreaudiod”.
- ”coreaudiod” starts a real-time thread for each new CoreAudio client (that is another RT thread beside the one the audio applications owns)
- since ”coreaudiod” is the only process interacting with the audio device, it actually “shares” the related processing: in particular some possibly heady DSP processing (like the one done on laptop to protect speakers…) is now done once instead of several time like in the old design.

Anonymous said...

so in snow leo every process do it, in lion only the coreaudiod, its a feature, not a bug:)

Anonymous said...

sudo launchctl stop com.apple.audio.coreaudiod

worked fine for me but interestingly, it killed Microsoft Communicator at the same time. Never used that for any audio/video conversation though.

No idea if it is related, but I thought it's worth mentioning if it gives any idea to others :-)

Andy said...

I also noticed a "coreaudiod" sucking up 10+% of CPU, so I went and Google'd and found this page.
My observation reflects the comment above re. the "coreaudiod" daemon doing all the processing of signals from/to audio devices:
System Preferences -> Sound, Input: if I uncheck "Use ambient noise reduction", "coreaudiod" goes down to approx 1.7%.
If I re-check "Use ambient noise reduction": "coreaudiod" goes back up to approx 5.2-5.3%.
This is completely reproducible.
(The only puzzle is why, after re-checking "Use ambient noise reduction", its CPU usage did not go back up to 10+%?)

Anonymous said...

@Andy It makes sense because as stated before, Coreaudiod deals with all things going through your computer's in/out sound. So at all times your computer will be finding out what is ambiant and what isn't. This also explains the comment before about plugging in headphones because when headphones are plugged in the ambient noise isn't tested anymore

Anonymous said...

My coreaudiod was shooting up to around 100%, and would sit at around 40% once I quit any app that was using sound. Even adjusting the volume would trigger it.

I tried about 30 different thing and FINALLY solved the the problem.

I grabbed the Library/Preferences/Audio folder from another mac and threw it in my Preferences folder as mine was totally missing, rebooted and boom, completely fixed.