|
|
|
[
Permlink
| « Hide
]
dimentox travanti added a comment - 17/May/07 05:33 PM
Adding.. It played the sound again when i edited the object it was in. randomly.. Some people are reporting it plays it when they use backspace.. I am not able to replicate it.
This has something to do with preload sound. I took out a preload in a completely different script it does not seem to act strange anymore.
Will continue testing to verify this Verified..
llpreload sound Create an object select teh object then selct tools and reset the scripts after clicking a bit (you only hear the sound once) I belive its because you play a sound and then play it again before the preload finishes Script 1 playit() } touch_start(integer total_number) { state play; }} state_entry() { playit(); state default; }} SCRIPT 2 touch_start(integer total_number) { llSay(0, "Touched."); }} } THIS IS NOT A DUPE..
The object spams a sound.... Preload is broke yes but its if you use preload with other sounds you have not even preloaded. NOT A DUPE
Object spams sounds it would be logical for PlaySound to interrupt the current sound, unless the calls were made from separate prims. You should be able to avoid with a call to llStopSound first. Both Play and Stop, unlike many functions return in under 0.1 seconds.
– Please read VWR-291, and see if those behaviors relate, if so add to that. – Are all the state changes necessary for reproduction? I'm taking it this is a scale-down of a production you are making. Also is "bull" the same sound as "f5b54cd2-2c2b-c659-1b19-a393063c6ca5". When you use a string to identify a sound, then it needs to be in the objects inventory. Is it necessary for reproduction, to refer to the sound by both key and name? Presumably, SL just reverse indexes named sounds to their UUID. If it is, how long is the sample, so I can make a similar sound. Is it necessary for reproduction to have two scripts? Does this simplified version, reproduce your bug Script 1: default touch_start(integer total_number) { llPlaySound("f5b54cd2-2c2b-c659-1b19-a393063c6ca5", 1.0); }} – Also please rephrase, "Preload is broke yes but its if you use preload with other sounds you have not even preloaded. " I hate to bug about grammar, but I'm having trouble understanding what you mean. I can confirm that this bug is affecting SL v1.16 as well (and breaks many of my toys, as I use llPreloadSound() in them). Here is what I found out, yet: you need to preload either a few large sound files or many little sound files... It "sounds" like (pun intended) a buffer overflow to me... Here is the script I used in a single prim object, and with the library/gesture sounds from '"Fore" female' to 'Laugh Male 2' (when the inventory is sorted in alphabetical order). If you put only a few sounds in the prim, the bug might not trigger:
default { on_rez(integer param) { llResetScript(); } touch_start(integer num) {
integer n = llGetInventoryNumber(INVENTORY_SOUND);
string sound = llGetInventoryName(INVENTORY_SOUND, (integer)llFrand((float)n));
llPlaySound(sound, 1.0);
} I can confirm that I've seen this same behavior in some of my other objects. A random emitter system that calls on a single clip will loop several times before moving on to another inventory selection. This behavior just started to happen very recently as well.
Agreed that this may be related somehow to the changes implemented in the llSetSoundQueueing function, but is definitely separate from the VWR-291 issue where the client inserts 10 seconds of dead silence in the place of aborted audio transfers. I'm wondering if this is some kind of poor management of assets on the client.
Theoretically, the system works by forcing clients to download preloaded songs when they are within a certain range. Then when a server calls them to play the sounds, they look in their local cache to see if it is available. Then play it according to the directions given it - as such-and-such volume, from the right. But, there's got to be a disconnect somewhere, possibly there's bad calls from the server or it's not compensating for packet loss. Is there any debug output when this behavior occurs? - I'd like to see if we can distinguish this from VWR-291. Is still happening to me. My script does the following:
llSetSoundQueueing(TRUE); Even with the two stop sounds I frequently have sound2 repeating on me long after the script finishes executing. But not as though it were using llLoopSound, there is some kind of random delay. The script has some particles I omitted which are not re-appearing so that rules out loops. I can completely agree with DT that preload seems to be causing the majority of this issue. I only have 3 scripted objects that really seem to suffer from this problem, all of them use preload. Also of note (as I haven't seen it anywhere). If a sound refuses to play in this manner, I find it in my inventory, double click it, then open it, and then hit Play Locally. 90% of the time, this causes the sound to play multiple times (at the same time). If it really gets stubborn, I sometimes have to repeat the double-click, open, Play Local a few times. In this case, it usually plays alot of copies at the same time. Once the inventory trick gets a sound to play, all llPlaySound calls work properly from that point on (even it it's preloaded again).
For some reason, double clicking it many times, or just opening the sound and hitting Play Local many times does not seem to do the trick. Was having same problem and came across this JIRA issue:
"New script" to create a simple particle&sound effect. Happened upon this quote on forum post: http://forums.secondlife.com/showthread.php?t=205975&highlight=llPlaySound "Also, after testing I find it only happens to newly compiled scripts." I therefore deleted the newly created script from 'Contents' and found a similar one in 'Inv'. Placed this into 'Contents', made a few parameter changes, added the same llPlaySound() from the original script & hey presto, all is working. I updated this entry to reflect the fact it still affects v1.18 viewers, although, in v1.18.3.2(RC), the sound spamming occurs only once, just when a new sound is played (i.e. the preloaded sound which was played once by the script, will be played once more when another sound is played from another script, or from the UI).
This bug is still present in v1.18.4.3 (see my 03/Jun/07 comment for a solid repro).
As noted in my last comment, the spamming yet now only occurs whenever a sound is played (either from a script or from the UI), after the preloaded sound was played from the object where the preloader script ran. Yet, there seems to be a new twist in v1.18.4.3: the preloaded sound is played again each time another script plays a sound (while it only happened once in v1.18.3.5), and this till a UI sound is played (at which point the preloaded sound is played a Preloading a NON EXISTING (or not loading) sound asset will cause sound spamming. This is 100% repro.
Example: on_rez(integer num) { llResetScript(); // force another preload on rez, to make bug persistent } touch_start(integer num) {
llPlaySound("5b9a73aa-e4ca-b60a-f4a4-860315b7d75e",1.0);
} ----------------------------- I can confirm Damanios' repro. That sound is repeating intermittently several minutes after being played only once
This bug is still present and makes llPlaySound more or less useless. It seems that the looping sound is only audible to the creator/owner of the object from my experience.
I can also confirm this bug and add that it is absolutely awful. How many hours have we all spent trying to diagnose the erratic sound behavior of our well-written scripts? MANY I confirm that removing llPreloadSound() does fix/mitigate the problem. There should be a HUGE WARNING on the LSL Wiki and the LSL Portal about this.
As what I can see, STILL present in 1.19.1
spent several hours too testing my scripts, i wonder why they don't fix this bug This issue is still happening in the late 1.19 client, and the new 1.20 clients... How ever it is not happening for everyone. It only seems to happen under the "link_message" and "sensor" events, and is triggered when there is script activity (most of the time not even in the same script).
Example: A scripted button in a child prim triggers a script in the root prim, the root prim says something in llOwnerSay(), and plays a sound. The sound plays once, and after a few minutes, something in the script is triggered by sensor... The sound that played a few minutes back starts looping for no reason, and there is no Owner Chat in the window at all, even though the sound is only in that one script. Some people experience this issue, some don't. So far, both me and my alt's, on all of my computers in my home have experienced it, and it happens quite often. Still happens.. Why did you close it with contact support?
Thanks Dimentox - I'm going through and re-opening quite a few of these
 I appreciate your help! I can't understand why this was closed, and happy to see it reopened. This broken llPLaySound behavior most certainly exists. I have several sound players I've bought that are totally broken now, repeating the last segment over and over, looping mid-segments arbitrary times, etc.
We spent a good deal of time recently trying to find out why a sound from HUD we were developing was playing when it shouldn't have been when we found this jira entry. While at times it does seem random, most of the time when it played without being triggered by the script, it was actually being triggered by the first instance of a client event after attaching the HUD - opening a Search window, opening or closing a chat window, and putting the object (or even other objects) into Edit mode seemed to trigger the HUD sound. Even at that, it wasn't consistent, but it occurred enough to demonstrate some kind of connection.
I was using client v. 1.20.17 (98669) Odd bug. Unreliable playback, and inconsistent errors - sometimes Playsound works, sometimes it doesn't. Annoying - simple call should be reliable.
Broken! Severely! Sometimes it works, sometimes it doesn't. Loops when there are no loops. Not playing at all sometimes. Erratic.
With the reliability of sounds playing an issue, many are shying away from some products that were our best sellers. This is having a HUGE negative impact on our holiday business. Sounds are being repeated and the sequencing is interrupted for the course of the play. BIG ISSUE!!!! Let's get this one fixed...PLEASE!
I am doing theater projects iSL, and sound fx are often critical to the quality of performances. Sounds that play randomly when they're not supposed, repeat when they're not supposed to, or don't play at all - that 's a huge problem.
this is really annoying and i hope it will be fixed soon
I use sounds fairly often in my builds. I need them to be reliable.
Ambient sounds are a big part of the SL aesthetic - using good earphones is akin to getting a new graphics card - it opens up a new world. Reliable play is pretty much essential unless users limit themselves to completely random sounds, which be definition will not artfully match the environment.
I have also this bug effecting my product which has a script which uses preload of sound. Really annoying bug.
Same here. Its annoying, but not nearly as annoying as the bug being 1½ year old
 I'm not very technical but I think things should work consistently. It is very annoying to listen for a sound that doesn't happen or that happens incorrectly
I would like this bug to be fixed immediately. It's inconceivable that the creators of Second Life could be satisfied without complete auditory access and fulfillment.
Thank you Minuete - the problem has been fixed in one of our internal branches. it will slowly percolate through QA and in the main viewer over the next couple months.
For me it plays repeated too and even plays other sounds then specified.
Using the actual release client version 1.22 So here my test script: touch_start(integer total_number) { llPlaySound(llGetInventoryName(INVENTORY_SOUND,0),1); }} I have put this into a prim with the 3 library sounds. Obviously, it should only play the first sound in inventory. We tested it with a few other people and sometimes it plays not at all, sometimes once, sometimes more often and even up to 4 times which is the amount of items in the object inventory. coincidence? Now comes the confusing part: Ok glad it is fixed internally. Hope to have the fix in SL soon since I created a boatload of sound scripts and people keep asking me why this loops when there is no loop int he script. When are we going to see some action here? Sound is such an integral part of the world I would think it would be a priority.
I beleive there is lots of behind the scenes stuff happening with sound at the moment as they're looking (and i beleive implemented in a linux branch of the viewer) at changing to the Open AL sound system from the currently used FMOD sound system and so i think all sound commands will be looked at closely and given an overhaul while the change over takes place
mhhhhmmmmmmm...crazy sound...and linden's family ?
Have they never read the pages about this bug ? Is in all the world someone of linden that can take this as first job to do ? Ah, so the weird "ghost triggers" that are annoying me for so long have a name: VWR-770
Sounds like an influenza strain  .I just found that this problem does not occur when using the Hippo client. Same scripts, same sounds/ keys, same everything, but no spamming sounds there. So I'll refrain from using SL clients until this is resolved. The full homestead sim that I've created uses sounds to complete the aural picture. Please take care of these issues soon.
Please give this issue priority, sound-scaping is integral to the sl creative experience.
I can confirm this bug, and it's really annoying! It's almost impossible to create an object with some sounds triggered. Most times it works perfectly, but sometimes it starts to play sounds randomly. Sometimes sounds are even triggered when using the menu!
It seems that cleaning the cache fixes this problem for a while. Second Life 1.22.11 (113941) Mar 6 2009 12:27:34 (Second Life Release) You are at 223026.3, 306226.1, 29.0 in Atmosphere located at sim3629.agni.lindenlab.com (216.82.22.110:13002) CPU: Dual i386 (Unknown) (2400 MHz) libcurl Version: libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 my understanding is that this bug fix will appear in the 1.23 RC.
I tried the 1.23.RC1 and the sound playback problem is unchanged. Queuing is still broken. In a serial playback case, (play S1 ... Sn), the viewer repeats playing S1 several times even though S2,S3... have been sent. The problem is mostly around the initial queuing, if often gets better after a while, though when a glitch happens, the same replaying occurs for a while. I tried prestuffing the queue with silent sound, but that does not seem to help.
The pipeline is: play S0, zero volume playtime = nowtime The actual time-delay implementation is one of two approaches: Balpien - that sounds like a different problem/bug. this issue is related to preloading bad sounds, which causes spurious playbacks at random times.
if you've got a different bug, you should file a new jira, i think. otherwise all the different issues start getting confused. Bug is still very much in release canditate 1.23.1. My sounds still keep playing randomly and repeatly. No fix so far
I'm glad to see this issue is being worked on. I'd just like to point out that, in my vehicle, in the standard viewer, this is happening with llTriggerSound as well. All's fine when none of the sounds have been played, but as I work things in my vehicle that generate sounds, those sounds are being repeated at random control inputs, when the vehicle is selected, bumps into something, or really with any stimulus at all.
I had set everything to llPlaySound when I built it, perhaps because that was working at the time, or perhaps I didn't give it any thought, but I switched all the scripts to llTriggerSound to fix it, but it's still exhibiting this behavior. Lexo - can you give me a copy of your vehicle?
I am now using version release canditate version 1.23.4 and as i have used 1.23.1 and now 1.23.4 and same bug is still on and lPlaySound playes sounds randomly and repetedly.
Fixed in 1.23.4, released on 06/15/2009.
No, I don't think that this issue is fixed. After about two weeks working on a object (which hadn't this behaviour before), today it startet again to play sounds randomly.
Edit: Today, it's still the same. Sounds trigger occasionally...
Let me highlight that all this is EXTREMELY ANNOYING!!!! Second Life 1.23.4 (123908) Jun 11 2009 14:53:39 (Snowglobe Release) Built with GCC version 40001 You are at 223035.4, 306237.5, 29.0 in Atmosphere located at sim5712.agni.lindenlab.com (216.82.51.14:13002) CPU: Dual i386 (Unknown) (2400 MHz) libcurl Version: libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 Reproduces for me on current versions of main viewer, Cool Viewer, Emerald, and Snowglobe.
Second Life 1.23.4 (0) Aug 1 2009 14:03:51 (Cool SL Viewer) Built with GCC version 40001 You are at 233749.6, 217423.4, 27.0 in Atlantis Archipelago located at sim3793.agni.lindenlab.com (216.82.23.20:13001) CPU: Dual i386 (Unknown) (2800 MHz) libcurl Version: libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Reopened
Major
llPlaySound() Sometimes loops sound or wont even play.
