llPreloadSound() questions

Hi folks,

I had a few questions about llPreloadSound() and the wiki didn't quite answer them (either the mirror is out of date or it's just not in the entry).

1) llPreloadSound() has a script delay of 1 second, and preloads the sound to the cache of anyone nearby yes? Is there a limit to how many sounds can be preloaded? If I am playing a sequence of 9 second clips, I could in principle play a clip and preload the next one immediately yes? I'm assuming the script delay wouldn't matter if llSetSoundqueueing was on. Incidentally, if you have sound queueing on, you can only have one extra sound in the queue right? Does a preloaded sound count as a queued sound?

2) If you preload a sound that is longer than 1s, does it take longer to preload? If I had a preload command followed by a playsound command would the sound play after 1 second?

3) Can anyone explain why some scripts choose to play a sound at 0 volume instead of using llPreloadSound()?

I've tried experimenting a bit, but it is difficult of course because once you play a sound it is already in your cache. Is there a way to clear your sound cache aside from logging out?

Thanks for any help. The forums and LSL wiki have been great!

Sorry, my own experience with llPreloadSound() is a little sketchy... and
I haven't seen too much clarification on it.

One of two things happens:

Preloading a sound basically issues a "Play at zero volume" to everyone in hearing distance, causing the clip to be cached on people present.

or

Preload sound sets an attribute of a prim, like putting a texture on a hidden face so that anytime someone is nearby it's likely to be in their cache and ready for use.


I had been leaning towards the second behavior... but experimentation seems to indicate this is not the case.

And yes, even for sound clips less than one second the delay still counts. The issue is "time to load into cache" not play-time length of the clip.

Also clips fade from client cache after a while if not used just like everything else, I would expect.

In my experience, llPreloadSound() had no effect at all that I could discern. I think that might be why some people opt to play a sound at 0 volume instead, which should, theoretically, have the same effect as preloading unless a 0-volume sound is ignored by SL.

1. llPreloadSound() has a script delay of 1 second, and preloads the sound to the cache of anyone nearby yes?
   Yes, it downloads the sound to the cache of all nearby avatars. I do not know the distance but I know it's greater than 100m.
   
   
   Is there a limit to how many sounds can be preloaded?
   You can preload as many sounds as you like, but the performance is limited by internet bandwidth.
   
   
   If I am playing a sequence of 9 second clips, I could in principle play a clip and preload the next one immediately yes?
   Yes you can preload another sound while playing one already cached.
   
   
   I'm assuming the script delay wouldn't matter if llSetSoundqueueing was on.
   Once a sound is started, script delay will not affect its playback.
   
   
   Incidentally, if you have sound queueing on, you can only have one extra sound in the queue right?
   Yes only one sound is queued to play after the current one. Playing a sound with one already queued will place the new sound in the queue, bumping the first one out which will then not be played.
   
   
   Does a preloaded sound count as a queued sound?
   No, preloading sounds do not affect the queue, only played sounds.
   
   
   
   
2. If you preload a sound that is longer than 1s, does it take longer to preload?
   Yes it can take much longer than 1 second to preload a sound. It depends on the file size not just duration, as the recording bandwidth is variable at upload time. I've seen it take more than 10 seconds for a single sound.
   
   
   If I had a preload command followed by a playsound command would the sound play after 1 second?
   No, if you play too soon it will still wait till the sound is completely cached to start playing, negating the effect of llPreloadSound(). In this case you might get the impression that preloading has no effect, as expressed by Lex. It takes as long as it takes.
   
   
   
   
3. Can anyone explain why some scripts choose to play a sound at 0 volume instead of using llPreloadSound()?
   I can think of three reasons, either they didn't know about llPreloadSound(), it didn't exist at the time, or they wanted to get around the script delay, which IMO is there for a reason.
   
   

If an avatar arrives after the preload was initiated, they do not preload it, so I doubt it's any sort of prim attribute. From what I have seen, most cached sounds are flushed each time the SL client is closed, especially the large ones.

Thanks for the feedback, especially Boss' comment about the preload taking much longer than expected. It helps me understand why, for example in Psyke Phaeton's music script, the buffer time is so long. I have been playing around with Psyke's script as well as one i wrote, and I have not really found one that has a good compromise between long buffer time and smooth playback.

I had been thinking of how to create a music box script which also worked well for newcomers. I wonder if something like the following compromise would work well. I'm going to pretend it takes roughly 3 seconds per preload, and I am using 9 second clips, We would start with something like this (please don't consider this actual code, more of a sketch):

Sound Queueing is on.

integer cliptotal = 20; // just a random number of clips, global variable
on touch:
clipnum = 1;
llPreloadSound("sound" + (string)clipnum);
llPreloadSound("sound" + (string)(clipnum+1));
llPreloadSound("sound" + (string)(clipnum+2));
llSetTimerEvent(8.9);

then
timer()
{
llPlaySound("sound" + (string)clipnum, 1.0);
clipnum++;
if (clipnum == (cliptotal + 1))
{
clipnum = 1; // restarts the looping song
}
// the following preloads the next 3 clips, unless the song is nearly over.
if (clipnum < (cliptotal + 1))
{
llPreloadSound("sound" + (string)clipnum);
}
if (clipnum < cliptotal)
{
llPreloadSound("sound" + (string)(clipnum+1));
}
if (clipnum < (cliptotal - 1))
{
llPreloadSound("sound" + (string)(clipnum+2));
}
}

Maybe the repeated preloads of sound clips are overkill, but it seems like it would help a newcomer's sound cache get up to speed.

Your sketch would take 11.9 seconds before starting to play (3 preloads + 8.9 seconds before the timer fires)... and asks the system to download all 3 at once. You might try structuring that part something like this:

llPreloadSound("sound" + (string)clipnum);
llSetTimerEvent(8.9);
llSleep(2.0);
llPreloadSound("sound" + (string)(clipnum+1));
llSleep(2.0);
llPreloadSound("sound" + (string)(clipnum+2));

This gives the system 9.9 seconds to preload the first sound, and 18.9 seconds before it needs the second one, etc. That way you can make the sleeps larger if necessary and it still starts soon after the third preload is started. Making them larger than 3.0 will of course delay the start since the timer won't fire till this code returns, but the second one should be on time. You could also move the llSetTimerEvent() lower to adjust when that first triggers.

One other note, considering this pseudocode

if (clipnum == (cliptotal + 1))
{
    clipnum = 1; // restarts the looping song
}

I believe you want this to be if (clipnum == cliptotal) since your index starts at 1, and cliptotal is a "count" which also starts at 1:

timer()
{
    llPlaySound("sound" + (string)clipnum, 1.0);
    clipnum++;
    if (clipnum >= cliptotal)
    {
        clipnum = 1; // restarts the looping song
    }
// the following preloads the next 3 clips, unless the song is nearly over.
    if (clipnum < cliptotal)
    {
        llPreloadSound("sound" + (string)clipnum);
    }
    if (clipnum < (cliptotal - 1))
    {
        llPreloadSound("sound" + (string)(clipnum+1));
    }
    if (clipnum < (cliptotal - 2))
    {
        llPreloadSound("sound" + (string)(clipnum+2));
    }
}