Cleaning up CoreAudio preferences

The files on the test machine now have become >1Mb and the system keeps recreating them.

Ouch. I suspect what's happening is that you're presenting the devices you create in a way that makes each of them appear "unique" which is probably worth avoiding/thinking about (see #2 below). However, that's 1Mb is also getting a bit absurd (a plist file is not a database), so please file a bug and post the bug number back here. Make sure you attach the plist files to the bug so the team can see what's actually going on.

1. How can I manually remove/cleanup these files? (This is for development only. It already became pretty tedious to evaluate current device settings for debugging purposes.)

I'd just delete the entire file the reboot*. You'll obviously lose data, but the system should recover automatically. If it doesn't then it's our bug** that we should fix.

*The reboot isn't necessarily required here. I recommend it for this sort of thing because it's the best way to ensure you've returned the system to a "known" state, minimizing ANY possible issue.

**The system is sufficiently complex and used for such a broad variety of tasks that "don't do that" is not a reasonable data management strategy. Our components should either self recover (which is what I expect to happen here) or prevent the data from being modified/deleted. This is particularly true of any kind of "Preference", where the definition basically includes "the system doesn't REALLY need this to work".

1. How can the CoreAudio server plugin make sure once a device has been removed also its entries are removed from the .plist (It already removes it's storage, but the system still keeps other settings.)

Unfortunately, I don't think there is any good option there. If possible, I would try to manage your devices such that you avoid creating "growth" wherever possible, but that's all you can really do.

1. Is there some documentation about what gets stored and how the settings are organized in these preferences? (This is also for development and debugging only. We are not intending to access these settings directly )

We've never documented any of this, though it's not hard to infer what's going on if you look at the data.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank Kevin,

Ouch. I suspect what's happening is that you're presenting the devices you create in a way that makes each of them appear "unique" which is probably worth avoiding/thinking about (see #2 below). However, that's 1Mb is also getting a bit absurd (a plist file is not a database), so please file a bug and post the bug number back here. Make sure you attach the plist files to the bug so the team can see what's actually going on.

Yes, they currently appear with a different UID each time. This needs to be fixed on our side. But I am not sure if the file size is an Apple bug. Isn't it more an unexpected use of this system? Anyway, as suggested I filed the bug report FB17384333.

I'd just delete the entire file the reboot*. You'll obviously lose data, but the system should recover automatically. If it doesn't then it's our bug** that we should fix.

I would love to lose these data though; unfortunately everything recovers!

sudo rm /Library/Preferences/Audio/com.apple.audio.DeviceSettings.plist
sudo rm /Library/Preferences/Audio/com.apple.audio.SystemSettings.plist
sudo reboot

...and magically everything appears untouched.

Thanks for all your help and suggestions!

Yes, they currently appear with a different UID each time. This needs to be fixed on our side. But I am not sure if the file size is an Apple bug. Isn't it more an unexpected use of this system?

Yes and no? The bug here isn't a case of "this is an obviously wrong situation we must fix now". The circumstances are obviously involved and some of the issue can/should obviously be addressed on your side. However, the behavior is also unexpected/odd, particularly since you can't trivially correct it (see below), so it's worth documenting so the team is aware of the issue.

Anyway, as suggested I filed the bug report FB17384333.

Perfect thank you.

Moving to here:

I would love to lose these data though; unfortunately everything recovers!

So, that makes things more interesting. 3 things I'd try, roughly ordered by "safety":

1. Move the file to the side, reboot, then delete-> This will only work if CoreAudio is holding the file open (so don't be surprised if it fails), but it's what I would try first.

2. Move the file to the side, and replace with a new plist file-> I'd expect this to work, but it's possible that CoreAudio is "blindly" pushing it's pref data back to the file. Again, this is "safe", so it's easy to test.

3. Quit/shutdown everything you can, do the same thing as #2, and then more "aggressively" terminate things. It's not something I'd ever recommend as a formal practice, but terminating (kill -9) coreaudiod (followed by a reboot...) would probably work.

More broadly you could also to the same thing to the entire system using any of these commands:

sudo reboot -q (n)
sudo halt -q (n)

sudo kill -9 1 (terminate launchd)

All of those should immediately terminate the system without providing any time for new data to be written out. Functionally, they're only slightly better than cutting power to the machine, so they are somewhat dangerous but shouldn't be an issue as a one off/occasional option.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thanks again, Kevin,

taken from your suggestion the most convenient way of resetting the CoreAudio server preferences without rebooting seems to be:

# clear CoreAudio preferences
sudo truncate -s 0 /Library/Preferences/Audio/com.apple.audio.*

# change owner to prevent rewrite
sudo chown root /Library/Preferences/Audio/com.apple.audio.*
sudo killall coreaudiod

# reset owner to allow rewrite
sudo chown _coreaudiod /Library/Preferences/Audio/com.apple.audio.*
sudo killall coreaudiod

Thanks

taken from your suggestion the most convenient way of resetting the CoreAudio server preferences without rebooting seems to be:

Sure, I can see that working. Two small notes:

1. I really do recommend rebooting after this sort of thing. It often won't matter but sometimes it does and, most importantly, it's really hard to predict whether or not it will. You can choose to live dangerously (I've done so a few times myself...) but the real risk here is if/when something like the becomes "routine" and then LATER something breaks. You can end up wasting a lot of time trying to investigate a problem which looks serious, but is actually just a trivial issue caused by failing to reboot.

2. As a standard disclaimer, this isn't the sort of thing that normal users/customers should ever be doing (or even need to).

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware