Sequenced sound, the age old issue.

[badboymercy]

Sequenced sound playback is terrible in LSL, trying to make something play back smoothly, even with preload or using queue there's still delay that is very noticeable and annoying. Preloading doesn't work like it should and neither does sound queuing. Perhaps intentionally having 8 second clips with 1 sec silence at the start and the end or something would help, but the issue would remain. I was hoping you could play sounds at 0 volume on a second prim to preload them during the playback of the first sound so it would be ready and actually preloaded for when the first sound had finished playing. But it doesn't seem you can proxy sounds from a prim into one of the links, thus having two sets of the same sounds would leave you with two separate preloaded sounds in memory? Not sure. What if the script got the UUIDs and preloaded them by that, would this help make sure that the sound got cached properly and played smoothly? I've looked around a bit and gone through some of my own older scripts, but I can not find a smooth playback script that doesn't have issues. It is either: Delay between sounds when using preloading or using queue. or Sounds overlapping when trying to compensate by starting the next sound in queue early to compensate. I made a script for playback ages ago, it used to work well but that doesn't seem to be the case any longer. I've not tested using triggersound and playsound together to do this, guess I could play around some. Does preloaded sounds get scrapped from memory when the content is finally played? Does it even preload to begin with? Is cache even used for sounds? Have a good one~

[Rolig Loon]

When you "preload" sounds (or textures, for that matter), you are not loading them into the scripted object.  You are loading them into cache for any resident within range.  That's why you have to preload fresh every time that someone new enters the area.  Slide shows do that by loading "previewed" slides onto hidden faces so that they are "visible" to everyone's viewer for quite a while before they are finally moved to the face that shows the current (active) slide.  You could do the same thing with sounds.  In fact, where I have a collection of sounds to play in an area, I typically preload them all, sequentially, with a script that's triggered when any new arrival hits a collision prim at the entrance.  If you have visitors use a HUD that is in an experience, you could do the same thing by preloading sounds and textures from KVP when the HUD is attached.

Sounds never used to be cached "permanently", but LL changed that a couple of years ago, so I think they are always saved by default in your viewer cache when you log off, just the way that textures are cached.  You can change that default with a debug setting to save memory if you want, but most people have plenty of memory to burn.

Playing sequenced sounds is a bear, no matter what you try.  Preloading helps a bit, and so does llSetSoundQueueing, if you overlap your sounds slightly.  It also helps if you are religiously careful about making sound files have exactly the same length with Audacity before you upload them.  All it takes to mess things up is a little lag, though.