Second Life: Script-triggered Sounds and Viewer Audio Channels

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:

  • Music
  • Media
  • Voice
  • Sounds
  • Ambient
  • UI

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).

This entry was posted in How Marv would fix Second Life and tagged , . Bookmark the permalink.

2 Responses to Second Life: Script-triggered Sounds and Viewer Audio Channels

  1. Elric Ember says:

    Would be nice–and probably easy to reuse existing code–to assign a parcel media URL to the Ambient channel.

  2. SignpostMarv says:

    Personally, I don’t think it’d be an appropriate use of media streaming to pipe external MP3/Ogg Vorbis audio outside it’s existing channel unless the playing field was levelled to allow script-triggered sounds to be made omnipresent and media/music to be made spacial it won’t be as fun.

    Think along the lines of being able to have a script declare an object as being the spacial source for individual audio channels in a media/music stream, i.e. creating a pair of speaker objects, setting one to left channel, and the other to the right channel. This would likely improve immersion in a variety of scenarios: having your in-world TV hooked up to a virtual 5.1 surround sound system so you could practice placing the speakers before shifting furniture around your own home, or club having the speaker cabinets set as the spacial source so those wanting to use voice chat on the public parcel could congregate away from the speakers (similar to how one might behave in a physical club).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>