some sounds randomly don't play

I use sound pretty extensively in my SL app (largely a lot of narration.) I have come to find that a given sound file will randomly just stop working after a while. My player will get to the sound and *think* it's playing it (throwing no errors), but no sound comes out. While this is random, it tends to be the case that once a sound doesn't work once, it also does not work subsequently. Anyone have this issue? Anyone have a solution for keeping sounds "fresh" (as this seems to be a case of bit rot)?

I'm not sure why they would KEEP not playing, but generally I've found that sounds may take so long to load on the client that they should be done playing by the time they are ready. It would make sense that they'd stop playing after a while in an unpredictable manner too when the client removes the sound data from its cache. I gave up on a multi-sound music player a long time ago because it was just too darn erratic. No amount of preloading, preplaying, or anything else would get a song to play consistently, though when they DID play it was amazing.

You might try increasing the cache size on your client, but this is only likely to decrease the problem, not eliminate it. And unless you tell everyone else who visits to do the same, you're only changing it for yourself.

Sorry. Wish I had better news for you. Maybe someone else will come along and offer us both a nice surprise.

yeah, I'm systematically pre-loading everything, so it's not that. and this will happen even if there aren't very many sounds... so, dunno, it really does just feel like a case of bitrot. I will see if I can maybe preloading fewer sounds at a time. i'll have to make the preloading more dynamic. it's not a simple jukebox really, but more of a dialog that can branch in different ways depending on the user's actions.

my alternative is to just run a separate application in parallel on the user's machine to handle the playing of sounds and just sync it's actions to second life actions via xml-rpc. that's turned into my standard way of making up for Second Life's gaps in functionality, at least until something better comes along. it's a lame hack though...

I know trying to trigger a sound via play sound, while the same one is already playing gets ignored... and with recent inventory borks I'm noticing a lot of what's described above, clearing cache and relogging *should* fix the OP's problem, or forcing preloads (not sure if SL forces a new DL or ignores it because it's in the cache (though borked).. also I've had times where the load time just took so long to get the sound that I'd forgotten it shouldve been there

I think the problem is with sound queuing. I disabled sound queuing and that seems to have made this problem go away. It's also made some other bizarre Second Life audio issues I was having go away, such as a wav file that was recently played by my script being played again when a Second Life client GUI object (such as a dialog) generates audio.

It seems the only solution when playing audio is to wait *exactly* the duration of the current sound before playing the next. Since lsl of course can't tell you programatically how long a sound file is or when it is complete, I've had to resort to encoding the sound duration in tenths of a second in the sound file itself. now I'm getting acceptable performance. very tedious though...

There are some Jira bugs on sound and sound queuing, this list courtesy of Mordos Yering:

Sound queuing broken
https://jira.secondlife.com/browse/VWR-75

llPlaySound() Sometimes loops sound or wont even play
https://jira.secondlife.com/browse/VWR-770

Sound files often are not downloaded
https://jira.secondlife.com/browse/VWR-291

actually, I take it back. disabling queuing seemed to temporarily fixed things, but not permanently. the failures are still completely random.... nice that this is at least in Jira.

If you play the sound from your inventory, does it always work?

I always play sounds from the inventory of the object playing them and I always use pre-loading. Even so, I get about a 10% failure rate.

I have found that cutting my sound into exactly similar lengths, helps but not totally solves the problem. I use 9.99 second lengths of wave files and use a timer set at 10 seconds this seems to allow the delay introduced by the script. I have a piano and music box script that works this way they use preload and queuing. Goldwave software allows you to automatically divide your wave file into exactly the length you choose and to label them with consecutive numbers so splitting the original file is not much of a problem and loading them in the script can take advantage of the consecutive numbering.

Is your version of QuickTime up-to-date? I use llTriggerSound with SoundQueueing (without any preloading) in my wind chimes and I have a whole slew of them on display. I haven't had a single problem with sounds before or after the new asset cluster.