Not obvious enough that sound menu controls closed-but-playing player

One idea would be to make the sound indicator brievely appear green when an application playing audio back stops being visible.
The upside of this approach is that it would be consistant both with the messenging applet and with the current red-flashing behavior of the sound indicator when an application plays audio while the sound is muted. and probably very difficult to implement.

PS: @johnprattchristian you might have misused the tags field

Oops, I messed up, the end of the previous comment should read:

The downside is that it would probably be very difficult to implement

Yes, it would be tricky to detect when a player is minimised based on the current communication.
Although I do think there is a usability point of interest here, something which has been mentioned previously.

How about: If a player registered in the sound menu is playing sound when you close its only open window, the window should visibly zoom into the title of the sound menu. Is that plausible?

@matthew If that were possible to execute, that would certainly improve the user experience a ton! :)

Some players (like Amarok) have a gconf key along the lines of "first-time-tray-minimize". If it is indeed the first time it sends a notify-send message announcing "The player is still running in the system tray". Afterwards, the key is set to 0 and never bothers again.

Perhaps a similar announcement could be used? I'm not keen on the idea but it is some food for thought.

For me, classic minimize is enough for me to dismiss the application and I don't need a "minimize to tray" option. However, I understand that many prefer to have both, so how about adding a new window button called "minimize to tray" and have "close" still quit the application?

that's not really the point. the point is so the user understands what happened to their application. Why is it still playing if they closed it and its not in the taskbar. now, with unity, i don't know if that still applies