Don't click here unless you want to be banned.

LSL Wiki : llPlaySound

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are crawl805.us.archive.org
llPlaySound(string sound, float volume)

This function plays the sound file defined by sound (which may be either the key or name of the sound file--if it is in the prim's inventory). volume is a normalized float between 0 and 1 (if a volume is specified greater then 1 it's set to 1).

A script can only have one sound playing using llPlaySound; subsequent calls will be ignored until the first sound has stopped playing, unless llSetSoundQueueing has been enabled, in which case one sound will be queued and played as soon as the currently playing sound ends. This function returns immediately.

Sounds started with llPlaySound can be stopped using llStopSound. The volume of sounds started with llPlaySound or llLoopSound can be adjusted using llAdjustSoundVolume.

Note:No they can't. At least in version 1.16, llStopSound will not stop sounds started with llPlaySound. IT does work on llLoopSound, though. - WarKirby Magojiro 05/26/2007
Worx again since 1.17.1 -Altern8McMillan

Sounds played with llPlaySound and llLoopSound (and the master/slave versions of these functions) "stick" to the object playing the sound. That is, if a long sound is started with llPlaySound, and then the object moves away, the sound will grow fainter. Compare this to llTriggerSound and llTriggerSoundLimited where the sound stays at the location it was first played.

If llPlaySound is used in an attached HUD object, the sound will only be heard by the user wearing the HUD. Additionally, if the user is over land that is set to restrict sound from entering or leaving the parcel, the sound will not be heard at all. To play a sound from a HUD and have others hear it, use llTriggerSound instead.

Note: A call to llPlaySound() where the sound to be played is unavailable (ie. referenced by name but is not present in the object's inventory, or by a non-valid key) will delay the calling script by one (1.0) second. - Cross Lament 01/19/2007

PlaySound(string sound, float volume)
{//not fool proof but pretty reasonable for avoiding the 1.0 second delay if it does not exist
    if((key)name);
    else if(llGetInventoryType(sound) == INVENTORY_SOUND);
    else
        return;
    llPlaySound(sound, volume);
}//Written by Strife Onizuka

Q: Is there a way of finding out when the playback of a sound started with llPlaySound() ended? That would be useful for playing back playlists of sounds with the sound queue (i.e. queue another sound when one has ended).

A: Unfortunately, the only way to do this is to preload and wait, then use a timer set to the clip length. Sounds are not played globally synced, they preload onto each machine based on ping and available network bandwidth, and without sufficient preloading no two clients will hear the same sound at the same time unless it is already cached.

Note: There appears to be a bug with llPlaySound() on attatchments, it will play from the owner's cache(may be limited to creator, none of my customer's have reported this, but several other content devs have reported it in their own wares in their testing) at random seconds, or minutes later. No other avatars reported hearing the unplanned sounds in my, or the other developers' testing, using llTriggerSound() instead seems to have fixed the problem completely.

This article wasn't helpful for you? Maybe the related article at the LSL Portal is able to bring enlightenment and ink cartridges.

Functions | Sound | Client Asset Keys
Comments [Hide comments/form]
Can anyone confirm that HUD objects actually cannot use llPlaySound? According to my own experimentation and talking with Data Linden, that seems to be the case, though llTriggerSound does work.
-- AprilHeaney (2006-05-31 02:40:28)
It's too bad that parcel sound-blocking stops HUD objects from playing sounds to their wearers; it'd be excellent for private audio notifications otherwise. I'd send in a bug report, but I'm worried about what LL's "fix" for the problem would be. I don't want to lose this "llOwnerSound" capability completely.
-- PrioSerpentine (2006-07-21 12:40:42)
Alot of that decision comes from the differential in the two functions.

llPlaySound() plays at a dynamic location, following its creator.
llTriggerSound() stays static and plays at the location it was triggered from.

Heads Up Displays (HUDs) are static. The only way Linden Labs could (assumingly) allow llPlaySound, by its definition, would be to make the source of the sound appear to be the avatar. It would bring a tiny flaw to the two functions purposes.
-- BirdRaven (2006-07-21 13:55:50)
I'm not sure what you mean, Bird. llPlaySound does work in HUDs; it's just that the sound is only ever audible to the owner (which is good) and isn't audible at all if the parcel is set to restrict spatialized sound (which is bad).
-- PrioSerpentine (2006-07-21 18:47:38)
I meant globally. I know it does play to the owner :) It would just break the differential of the two functions if HUD llPlaySound were global, since that is the idea behind llTriggerSound :).. The Restric Spatialized Sound bug is just that, a bug. If that gets fixed then everyone is alright.
-- BirdRaven (2006-07-22 10:45:04)
The issue is that the hud is attached to the camera; so for it to track the camera position would be a waste of bandwidth. Also HUD attachments aren't technicaly inworld; or they are but they aren't. They are designed so that other users cannot see them (as such updates for them are only sent to the owner. It would make sence then that llPlaySound would only work for the owner.
-- BlindWanderer (2006-07-23 04:12:19)