Sound in HUD plays multiple times randomly.

[theangriestpossum]

I have a script that calls llPlaySound on a HUD object. Debugging tells me that it is only getting called on one time, yet the sound will play randomly a random number of times.

It's driving me crazy.

llSetSoundQueueing is FALSE.

 

Quote

// Paz Stuff - Thank you for using my script. Feel free to use it in any way you want. I use Firestorms LSL Script Preprocessing which adds features that normal LSL scrips do not have. The actual code can be found at the bottom of this commented code.

integer listener;
key owner;
string songName;
integer songParts;
integer songCount;

initialize(){
    llSetSoundQueueing(FALSE);
    llPreloadSound("intro_1");
    llPreloadSound("intro_2");
    owner = llGetOwner();
    songName = "";
    songParts = 0;
    songCount = 1;
    listener = llListen(997, "", "", "");
}

default{
    state_entry(){
        initialize();
    }
    
    on_rez(integer startParam){
        initialize();
    }

    listen(integer channel, string name, key id, string message){
        if(llGetSubString(message, 0, 35) == (string)owner){
            list stringList = llParseString2List(message, [" "], [""]);
            songName = llList2String(stringList, 1);
            songParts = llList2Integer(stringList, 2);
            songCount = 1;
            llStopSound();
            if(songName != "sound_stop"){
                llOwnerSay("play sound");
                llPlaySound("bone_break", 1.0);
                if(songParts > 1){
                    llSetTimerEvent(30);
                }else{
                    llSetTimerEvent(0);
                }
            }else{
                llSetTimerEvent(0);
            }
        }
    }
    
    timer(){
        llOwnerSay("timer event");
        llStopSound();
        songCount++;
        if(songCount >= songParts){
            songName = "";
            llSetTimerEvent(0);
        }else{
            llPlaySound(songName + (string)songCount, 1.0);
        }
    }
}
 

 

When I rez the same object in world, it plays the sound one time, correctly.

Edit: Rezzing in world does not fix this.

Edited March 23, 2023 by theangriestpossum

[Rolig Loon]

I know this may sound like a silly, "Is it plugged in?" question, but have you checked your work area to be sure that there are not extra copies of your script active in nearby objects? I ask only because I have made that mistake myself and have gone nuts trying to find a nonexistent script problem. It's very humbling. 

If that's not the problem in this case, I'm afraid I don't see an obvious answer.

[theangriestpossum]

14 minutes ago, Rolig Loon said:

I know this may sound like a silly, "Is it plugged in?" question, but have you checked your work area to be sure that there are not extra copies of your script active in nearby objects? I ask only because I have made that mistake myself and have gone nuts trying to find a nonexistent script problem. It's very humbling. 

If that's not the problem in this case, I'm afraid I don't see an obvious answer.

Yea, when I remove the object and do the listen trigger I get no sound played. I even rezzed the hud on the ground to make sure there were no duplicate objects linked inside of it. There are not.

[Rolig Loon]

Bummer.  It was worth a shot.

[Rolig Loon]

While I'm grasping at straws, I notice that you are using llPreloadSound, which can have the disadvantage that it causes a one second delay. When I want to preload a sound, I generally use llPlaySound at zero volume instead.  Also, I have sometime "preloaded" a sound by playing it in a completely different script, possibly triggered by code in my main script.  The sound is not being preloaded in the script, after all, but in each listening av's client, so it doesn't matter how you get it there.  I'm not sure how (or whether) this has anything to do with your problem, but it's a different approach to preloading. It might sidestep whatever your issue is.

[theangriestpossum]

17 minutes ago, Rolig Loon said:

While I'm grasping at straws, I notice that you are using llPreloadSound, which can have the disadvantage that it causes a one second delay. When I want to preload a sound, I generally use llPlaySound at zero volume instead.  Also, I have sometime "preloaded" a sound by playing it in a completely different script, possibly triggered by code in my main script.  The sound is not being preloaded in the script, after all, but in each listening av's client, so it doesn't matter how you get it there.  I'm not sure how (or whether) this has anything to do with your problem, but it's a different approach to preloading. It might sidestep whatever your issue is.

So... I removed the preloading from the script and it did not work initially. Then I detached and re-attached the HUD and now, without llPreloadSound, it is working correctly. This is so strange.

 

But whatever I guess, it all seems to work fine now. No repeating sounds at random.

Thanks for the help!

[Rolig Loon]

Magic is loose in the world. Solving the problem brings a lot of peace of mind. Knowing why it's solved would be best, but sometimes we take the victories we can get.  Congratulations. 

[theangriestpossum]

Here is how I recreated the bug:
 

 

[Wulfie Reanimator]

You should definitely post that video on LL's Jira so they can fix it. Really good demonstration.

3 hours ago, theangriestpossum said:

Here is how I recreated the bug:
 

 

 

[Marvin Benelli]

Nice trick Rolig, does that also mean you can preload all clips of a song in parallel using llPlaySound with zero volume in separate scripts?

[Qie Niangao]

Has anybody reproduced this? I tried, using the simplified script in the YouTube video, and the sound is only played once for me regardless of queuing and preloads. This on the latest Firestorm and Catznip both. Obviously it's happening, but not for me, so… what's different? Could it somehow be the specific sounds? (I just used whatever short sounds I had handy.) Or even some hardware-specific thing, somehow?

Or, if somebody else can repro it, then I'm just doing something wrong. 

This is the simplified script I copied from what I saw on the YouTube demo:

integer listener;
key owner;
string songName;
integer songParts;
integer songCount;

initialize(){
    llSetSoundQueueing(FALSE);
    llPreloadSound("intro_1");
    llPreloadSound("intro_2");
    owner = llGetOwner();
    songName = "";
    songParts = 0;
    songCount = 1;
    listener = llListen(0, "", "", "");
}

default{
    state_entry(){
        initialize();
    }
    
    on_rez(integer startParam){
        initialize();
    }

    listen(integer channel, string name, key id, string message){
        llOwnerSay("Sound Playing");
        llPlaySound("bone_break", 1.0);
    }
}

 

[Rolig Loon]

4 hours ago, Marvin Benelli said:

Nice trick Rolig, does that also mean you can preload all clips of a song in parallel using llPlaySound with zero volume in separate scripts?

I haven't tried pushing the experiment too hard, because I suspect that the answer will vary from listener to listener, depending the size of the sound cache in their machines.  For rather short clips, though, it does seem to work.

[Wulfie Reanimator]

2 hours ago, Qie Niangao said:

Obviously it's happening, but not for me, so… what's different? Could it somehow be the specific sounds? (I just used whatever short sounds I had handy.) Or even some hardware-specific thing, somehow?

Did you try in the same sim, maybe?

[Qie Niangao]

Yep, @Wulfie Reanimator, that's it. After I realized the region was evident in the YouTube video, I paid a visit and found I could rez with plenty of time to test, and… sound does not behave normally here. It is indeed very strange how it misbehaves—I'm not even sure what I'm hearing anymore, but it seems as if the region sometimes gets stuck on a script-played sound and will replay that sound instead of some other environmental sound. I get that impression because when it generates the spurious sound it seems to often happen immediately as I turn my avatar. But not always.

Anyway, I have no idea what about this region could cause the problem, or if the problem would just go away the next time the region restarts. (It's a 30K private region; before I was testing on a bog standard Mainland region.)

[Quistess Alpha]

10 hours ago, theangriestpossum said:

Here is how I recreated the bug:

Nice video, but I can hear your voice but not the sound that's supposed to be playing? (Oh! it's a typing sound, that's not confusing at all. . . ) maybe something louder and more obvious would have been better for demonstration.

Edited March 23, 2023 by Quistess Alpha

[theangriestpossum]

On 3/23/2023 at 10:57 AM, Quistess Alpha said:

Nice video, but I can hear your voice but not the sound that's supposed to be playing? (Oh! it's a typing sound, that's not confusing at all. . . ) maybe something louder and more obvious would have been better for demonstration.

Yea, its a bone cracking sound. Kinda hard to hear, I admit.

[Azimuth Somme]

I also currently have this issue, and the reason you hear it 'randomly' and sometimes when you turn (at least for me) is: The sound plays every time your viewer hears a sound for the first time after playing it.|
I have this with a HUD, if I play a sound (I have a few different types) when I right click, the sound plays again, when I open an IM window it plays again. When something in world makes a sound it plays again etc.

Unfortunately, no one else hears this, and I have made HUDs before and not had this problem. I have never used sound queuing, but I do use preload. I have even tried switching the scripts to another object and still have the issue.

[Azimuth Somme]

Wow after so long. turns out this curse is purely from PreloadSound. Removing that fixes the issue

[Judy Hynes]

Posting to add I still see this happening with llPreloadSound().  I drove myself crazy debugging the issue until I narrowed it down to use of this function, then belatedly found this thread afterwards.  Thanks to @Rolig Loon for the suggestion to "preload" via llPlaySound() at zero volume.  This is a very good workaround for my use case and shows no signs of the issue.