Yeah that would be great. Most apps like Notes, TextEdit or Activity Monitor or iTerm etc. do never play any music or longer audio segments. would be great to not have them on the menubar widget on by default.

Someone just messaged me on skype and the music I was listening to sort of got stuck, with the sound going "daaaaaaaaaaaaa" until I quit the app. Being able to ignore certain apps would provide a workaround this.

Maybe you could partially solve this by using a basic machine learning technic : apps are ignored by default, and added to the list the first time they play a sound.

Thanks for the suggestions, all. This feedback is really useful.

@Nosrac @momosby I'm planning to work on this problem soon. I agree that manually excluding apps will likely be the best solution, or at least part of it, but I haven't been able to spend much time thinking it through yet.

My initial idea for adding it to the UI is to replace the "App Volumes" title with a volume icon above the volume sliders column, and add a "..." button to the end of each app row, which reveals a menu that includes "Ignore for auto-pausing". Then add a few other things to that menu, like "Ignore completely", "Record audio from app", etc.

I'm also going to look into to using a smaller delay before unpausing when the music hasn't been paused for long. Combined with fading the music in and out, that should hopefully help a fair bit, too.

For the time being, you could increase the kPauseDelayMSecs constant in BGMApp/BGMAutoPauseMusic.mm. That will make Background Music wait longer before pausing, so ideally you'd have kPauseDelayMSecs set to the duration of the longest noise you don't want to trigger a pause. Of course, that will also mean your music will overlap with the other audio for longer.

The current value for kPauseDelayMSecs is just what worked for me. I'm happy to consider changing it for everyone. It sounds like I might have set it too low. We should probably also add an advanced preferences setting for it.

Actually, just looking at it now, kPauseDelayMSecs is set to 1500ms. That seems long for a notification sound to me. Your notification sounds might be playing inaudible, but non-zero, audio. That would be simple to fix: just checking for a minimum audible level in BGMDriver, rather than zero. I only haven't made that change yet because so far I've only encountered one app that seemed to send non-zero audio when it's silent. (OpenEmu, IIRC.)

But it's more likely that there's just a bug in the pause delay code. I just tested it locally using this beep sound and it seemed to work as expected.

Can you test with that beep sound and let me know if it's ignored for you? If it is, I'll try to figure out why it's not working with the sounds from Messages, Mail, etc.

@arnaudjuracek That's a good idea, too. I'll definitely look into it.

I would be a little concerned about having no apps in the menu at first, which could be confusing, but most apps actually do indicate, in a way, whether or not they ever play audio. To play audio, an app has to register itself as a client with Core Audio, which BGMDriver gets informed about. Technically an app doesn't have add itself as a client until it wants to play audio, but I haven't seen that in practice.

So I'm leaning towards showing those apps at first and hiding the others in a "More..." menu. Then apps would be unhidden (and stay unhidden) if they register with Core Audio. Of course, there are lots of apps that only play short sounds, or only play audio in special cases, but I think at least a few of the apps in @momosby's screenshot never play any audio at all.

Hiding completely silent apps is a fair bit easier to implement—at least, the main part of it is—I just haven't gotten around to it yet. BGMDriver can just send a list of all the clients to BGMApp so that BGMApp can hide those apps.

@wyred That's an interesting bug. Do you happen to know if it's reproducible? Also, which music player were you using?

My first thought is that it might be a bug in the audio playthrough code (which could be in either BGMDriver or BGMApp) that only shows up when multiple apps are playing audio at the same time. If it is, it could be pretty tricky to diagnose, even if it can be reproduced reliably. That would also mean that it couldn't be worked around by excluding apps manually, because every app's audio has to go through the playthrough code.

I'd like to enable logging in release builds to help diagnose bugs like this one, but it wouldn't be a trivial change. I didn't think to differentiate the logging calls in real-time code from the ones in non-real-time code. And I'm pretty sure logging isn't real-time safe, so I'd have to go through the real-time code to change all the logging calls.

This happens to me mostly when notifications come in for Messages.app, which happens to have longer drawn out/fading notification sounds.

This one, in particular, is the one that gives me the most trouble (Note):
http://www.zedge.net/ringtone/1665484/