Various ways in which sound has been broken since June 2004

The following quirky behaviors were introduced in 1.4-preview, not fixed by release-time, and are still present.

1. Client sometimes gets confused about the difference between llPlaySound() and llLoopSound(), especially if you turn on queueing and then call play() and then loop() without putting a sleep between them. So if you have a machine you are designing sound for, and it needs to play a startup sound and then loop a running sound, it will sometimes loop the startup sound (which was just supposed to be played once) and you never hear the running sound!
   
   
   
2. llTriggerSound() has a tendency to play the sound several times before finally stopping, even though you only call it once in state_entry() in a program with only one state. Number of spurious repeats is random.
   
   
   
3. llPlaySound() sometimes replays a sound that finished a long time ago whenever someone gets an update of the object. If I fly my plane to my house and land and get out of it, and it shuts down, it will replay the shutdown sound the moment my friend teleports in, or some green dot shows up near me on the map, even if the airplane has been sitting idle for half an hour. I confirmed this - "Did you just hear my airplane shutting down, even though no one is near it?" "Yes."
   
   
   
4. If you turn sound queueing OFF, llPlaySound() something, and then llPlaySound() something else before the first sound is finished, you will often get a nasty volume spike. If you are wearing headphones, it can be physically painful.
   
   
   
5. When you get an update on a faraway object that is looping some sound, sometimes it is played at maximum volume for a fraction of a second before it assumes the volume it should (which may be imperceptible to human ears, as the object may be over a hundred meters away.) So, if you are somewhere in the vehicle park, and someone starts riding a motorcycle, you will hear short blurping noises at maximum volume, followed either by silence or the sound of a far-away motorcycle engine.
   
   
   
6. Flying between parcels that have local sound turned on results in avatar/vehicle sounds pausing briefly.
   

It's been pretty close to half a year. When are these things going to be fixed?

Yes, llPlaySound() is pretty much ususable in anything that moves, like attachments for example.

You can make that go-away by playing with the doppler slider in preferences; of course, it's still a PITA.

Well, I was meaning the play-on-update thing. Try this:

- make an attachment
- add a PlaySound script, that just plays a single sound once
- when the sound has finished playing, jump up and down a few times

Now, on my system, this works as it should do: the sound plays once. When I jump up and down, I just hear my jumping.

However, I have it on good authority from multiple fairly independent sources that other people will hear the sound again and again, each time they jump, or collide with others (ie object updates).

Azelda

I have an object that replicates the ear-splitting volume burst problem. Kelly Linden has a copy of it too.

Huns,

thanks - agree these are things we need to fix. Is it possible to give me an object that repros each of these bugs separately? That would really help.

I will work on that today. Some bugs will not be easily reproduced right away.

OK, I have given you two objects that replicate some of these bugs. I think they should be enough to give you guys an idea. I also think that the bugs are probably interrelated, so finding and fixing a couple will probably lead to the rest being fixed.

My theory is that the client sometimes initializes sounds before it has fully figured out all the parameters.

For example, a sound will play before the client figures out the distance from the camera. The result is that the distance divisor is uninitialized and therefore zero, so the sound plays at full volume. A fraction of a second later, it figures out the distance, and the volume goes to what it should be.

For the sounds retriggering after they are done playing, and the object sends out an update because someone else shows up in the area, I assume the normal behavior is for the update to tell all viewers in the area that the object is playing a sound with time offset X. Well, let's say a sound was llPlay()ed starting 300 seconds ago, so X should be 300 (i.e. it was finished no fewer than 290 seconds ago and the client shouldn't play it at all.) If the client initializes the sound before X is set, X will equal 0, and the client will think it is supposed to play it from the start!

Of course, I could be way off. These are just educated guesses.

By the way, thanks for looking into this. I really appreciate it.

Plus there's the whole "static" problem. God, that's annoying. I realize it's not really too related to everything else in that list, but I hate how my sound will become annoyingly static-ridden for five or ten minutes straight.

the static thing sounds like a streaming problem.

It may be hard to fix, other than having a stable, bigger bandwidth pipe.

I doubt it, since the static can happen in the middle of a sound I've heard a hundred times before, and it always effects all sounds at the same time.

Ive notices all those problems. But the static one bugs me the most. It did this before and after they switched to there current sound system.

Just an FYI, they implemented the new sound engine in June.

Sorry for dragging up a very very old thread but I've just been scripting something with sound and have found that this still happens - even with sound queueing on. Was this fixed and then broken again in the period between this thread and now, or has it never been addressed?

but i have a couple attachments that only serve as 'audio ao's', for a couple new walking sounds (the default is so soft in volume, it's easy to overpower it by playing a new sound). if i remember right, it's a simple llLoopSound, with a corresponding llStopSound. however, i'll encounter every other day at least, a situation where i've stopped walking, but i sound like i haven't stopped walking, lol... this usually happens shortly after tping someplace, while the surroundings are still rezzin' up.

considering the tone of the thread, i'd place my bets on the sound commands, and not on my script. it never fails to trigger my sounds; just fails to stop them...