Second Life allows objects to be scripted to trigger the playback of sounds. These can include anything including (but not limited to) birdsong, gunshots, clicks and sound bites.
The viewer- or at least those intended to present the full audio-visual experience (there are text-only applications for accessing Second Life)- has an audio preferences panel, giving the user control over the sound levels of various channels:
There’s also the “Master” volume slider, but that’s not a channel per se.
Currently, all script-triggered audio gets piped through the “Sounds” channel- this allows you to mute in-world audio if you’re on a voice conference, mute the UI if you’re filming Machinima, or mute the in-world gusts of wind via the Ambient channel (though I’m not sure what else uses Ambient).
An idea that occurred to me that seemed to gain some interest in AW Groupies (hence the blog post here fleshing out the idea a little more) was whether or not script-triggered audio could/should have the ability to be declared as belonging to a specific audio channel, i.e. set sounds like birdsong, the roar of a waterfall or the trickle of a stream to the Ambient channel, so the sound level could be reduced or muted entirely, leaving the user more able to hear sounds like footsteps, doorbells, or anything else that’s intended to provide audio feedback to the user (such as the earlier gunshots example). CodeWarrior actually suggested that some script-triggered sounds might be more suitably applied to the UI channel rather than the current global “Sounds” channel.
This is obviously a feature that would require some server-side assistance to work as intended, though I am curious to know if it’s possible to have a viewer “intelligently” distribute sounds across the various channels, e.g. if a particular asset gets constantly looped, it should be shoved into the “Ambient” channel. Although not really suitable for long-term use (it would probably break a few intended behaviours in current content), it would certainly give a tangible demonstration of what effect any extra functions should have on the overall user experience. Then of course, there is the issue that any server-side solution would have to be done in such a way that was backwards compatible with non-supporting clients (e.g. not preventing script-triggered sounds from glooming into the global “Sounds” channel).