9

I'm getting my system log virtually spammed with:

May 13 23:56:36 alluminium coreaudiod[238]: Enabled automatic stack shots because audio IO is inactive
May 13 23:56:37 alluminium coreaudiod[238]: Disabled automatic stack shots because audio IO is active
May 13 23:56:38 alluminium coreaudiod[238]: Enabled automatic stack shots because audio IO is inactive
May 13 23:56:39 alluminium coreaudiod[238]: Disabled automatic stack shots because audio IO is active
May 13 23:56:39 alluminium coreaudiod[238]: Enabled automatic stack shots because audio IO is inactive
May 13 23:56:39 alluminium coreaudiod[238]: Disabled automatic stack shots because audio IO is active
May 13 23:56:39 alluminium coreaudiod[238]: Enabled automatic stack shots because audio IO is inactive
May 13 23:56:41 alluminium coreaudiod[238]: Disabled automatic stack shots because audio IO is active
May 13 23:56:41 alluminium coreaudiod[238]: Enabled automatic stack shots because audio IO is inactive
May 13 23:56:42 alluminium coreaudiod[238]: Disabled automatic stack shots because audio IO is active

Googling yields no useful results. Any ideas what this is and how to alleviate it?

4
  • I am receiving this as well. It seems to have started on 10.8.4 12E47 beta build for me. I did narrow down that it is logging in system.log whenever Mac OS X makes a sound action. Have not yet found a fix, but I don't notice any issue with my system, e.g. slow-down, glitches, etc.
    – booyah
    May 16, 2013 at 2:00
  • 1
    Which version of the OS? @booyah please do not discuss confidential pre-release software. Jun 2, 2013 at 19:02
  • @GrahamPerrin: you're right, I should probably ditch the whole topic, since I'm on a pre-release as well. Didn't think well enough before posting.
    – favoretti
    Jun 3, 2013 at 3:32
  • It's an honest mistake, easily made ;-) Also it's possible that these messages from coreaudiod are in a release, but so rare that they're not yet found by Google. I reckon, leave this question open for a week or so (WWDC in around a week) … Jun 3, 2013 at 3:51

3 Answers 3

5

Now that 10.8.4 is released (build 12E55), it is still there. I've gotten a response from Apple Engineering that this is logged by design.

2
  • 2
    by design? intentionally annoying people?
    – Duck
    Sep 11, 2013 at 3:56
  • 2
    Yes by design. it's a Notice level log message. Add this to /etc/asl.conf stop loging them: ? [= Sender coreaudiod] [> Level warning] ignore Oct 21, 2013 at 14:15
2

As best I can tell, these are purely diagnostic messages and don't indicate a specific failure and instead are just logging state changes for the audio subsystem.

If you wish to suppress those messages to have a clean log, it's quite easy to modify the logging system to not log specific or general messages for certain subsystems. Just edit your question if you don't know how to configure syslog.conf or ask a follow on question if that's your true aim separate from knowing that these are placed there by design.

You can also reduce the volume of these messages by determining which programs you are running that call the audio subsystem so often. If you log out of all accounts, you can convince yourself that the log only is reporting actions that your user level software is causing instead of some lower level system event that you cannot control.

2
  • 1
    The messages are level 5 (notice). Jun 2, 2013 at 19:01
  • 1
    One particular culprit I've found is Spotify; it seems to keep the audio system active at all times, whether it's playing or not. That causes a pair of these log messages every minute. Jul 11, 2013 at 8:58
1

On build 12E55, I've also been seeing these messages. At first, I downgraded coreaudiod back to 10.8.3's version but after playing with strings and dtruss, I found a way to stop the flood of these messages on my system with the latest coreaudiod (you still see the message once when coreaudiod starts but only then). Here is what you can try:

  1. Create /Library/Preferences/Audio/com.apple.audio.ServerSettings.plist with the following content:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
        <key>AllowStackShotsDuringIO</key>
        <true/>
    </dict>
    </plist>
    
  2. Reboot.

4
  • Consider the possibility that allowing stackshots may be disruptive. Jun 6, 2013 at 19:30
  • Fair enough, but given that the log here indicates the stackshots are happening very often anyway, I'd rather take my chances and have coreaudio do what it was going to do without logging it.
    – 93270
    Jun 6, 2013 at 19:39
  • I guess that enabling automatic stackshots simply allows the system to be prepared for the automation. I doubt that a stackshot occurs every time automation is enabled. Jun 6, 2013 at 19:45
  • You're right and I didn't realise that when reading the message. I won't delete this as I believe it should be for someone to decide whether the trade-off is worth it for them personally, but my post shouldn't be considered as an answer.
    – 93270
    Jun 6, 2013 at 20:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .