|
|
|
[
Permlink
| « Hide
]
Lex Neva added a comment - 24/Mar/07 08:23 AM
I've seen this happen. Occasionally, no matter how long I wait around something that I scripted listening to its sounds, one of the sounds never plays for me.
I've noticed this has happened with some inworld "record players" playing queued sound files. And yes, these were preloaded. Feels very shaky to me too.
I used to see this problem with older sound files that I had uploaded. Maybe 5 months old. On slower days, the client would just not trigger them at all. Either in scripted objects or even straight out of my inventory. Turning on the debug control window showed huge amounts of warning messages that it could not find the asset ID. Secondary attempts to get the sound to trigger would not yield any new debug messages. From what I can tell, it just isn't locating the asset information correctly. Things had been improving a bit, but now I am noticing sounds that were uploaded three weeks ago are not triggering.
@Hastur: Thanks for the added info, I don't think we have an internal issue on this yet, so let me keep track of this. We actually don't have a "Sound" component internally (Public JIRA's components are much simpler): we should!
I can confirm what Hastur wrote. The first times I complained about this in-world was because I could not hear my sound even if I played them from the inventory. Then, while another resident and a linden were present, I discovered that they could hear them while I could not. They were sounds that I uploaded the week before.
Does anyone have some test scripts you can paste here to flesh out the details?
Also see Debug console messages where the sound file download is aborted.
My observation (and i could be wrong, so don't flame me) is that for some reason, the SL client believes it has downloaded the clip... and plays only dead silence. This is very noticable if you have 2 or more clips playing back to back. If you try to trigger the clip 2nd time (from inventory for example) just dead silence... no new messages appear in the debug console. Fix? As stated previously, dump cache and relog will get the SL client to redownload the sound assets; however almost every time the BOOM, error in transfer aborted returns... You have to completely shut down the internet connection to get routed to the asset servers (not sure if this is accurately worded, but from the first notes in the JIRA ticket it does appear relevent). A simple sphere with this script inside
default { touch_start(integer total_number) {
llPlaySound("b2d08b72-fa8d-3104-bc64-0943c8a5d692", 1.0);
} used to show this behaviour. It was a little silly "sound gift". When I made it, some people (actually 80%) reported the object didn't work. Sometimes it happened that I gave it to someone and told him/her: "I'm sorry but sometimes it doesn't work..." then they touched the object and it worked for them but I could not hear the sound! Today it was working for me so I don't know it it's a good example. When today I touched the objected (the cache was cleaned many times from the last time I used it and also the viewer changed) I saw a small increase of the bandwidth usage followed but a much higher increase. Then the level wend back to a normal bandwidth usage and the sound played.
When it was not working (and this is true for other sounds too) I could see only the first "small" increase for each mouse click but it was not followed by the second one, that could be the actual download of the sound file. I'm guessing here. Don't know how it works but that's what I saw. Thanks for the info, Hastur and Rita. We're still trying to find a solid repro for this (see
 ) which formerly exhibited this behavior. I can reproduce it. Just drop by my place in Chebi (LM in profile). The machines I have out all play sound samples. I can be standing nearby when a visitor tries to trigger a sound clip, I have the debug console open (CTRL+SHIFT+4) and I see the file transfer down successfully and hear it play, however the other person gets the BOOM, ABORTED TRANSFER error. The behavior is different from avatar to avatar standing within the sound radius. So I went around browsing the different clips and several times I receive this aborted transfer error. I doubt the machines (Moopf GiftOpfs) are even using llSoundQueueing. As this happens at random, it may take a few tries before the client decides to drop the transfer again.
Are there any other methods that I can use to document this to move things along besides the debug console? Tested this out again at my location.
You are at 261717.0, 232272.7, 96.4 in Chebi located at sim842.agni.lindenlab.com (66.150.244.87:12035) Stood on an aisle with 5 of my sound machines. With the debug console open, I triggered a sound on each of the machines, switched to the next product, then triggered those sounds. After about 25 successful transfers, I got the BOOM,ABORTED message on one of the samples. Clicking on the trigger button returned no more console messages and no sound. Dumped the cache and logged off and back on. Clicked the same machine to play the same sound again, sound file downloads and plays without error. Which surprised me a little as I was connected again to the same LL server. From the earlier comments I indicated I had to shutdown the PC entirely to get a different LL server route as a terrible workaround. @Hastur: thanks for continuing to detail your findings and your patience on this. So the mode of reproducing what you experienced is: to stand by the machines and keep clicking them to play sounds, and sometimes, the sounds will not play?
If so, sounds straightforward enough and I can take a look at it soon. This issue is currently on the Studio Blacklight (dev team @ LL focused on critical Resident pain points) watchlist, but what's holding us back is lack of a clear repro we can follow. If we have that, progress is much more feasible. Also, in the future as we keep growing this Issue Tracker, we hope to evolve into a more organized procedure for triaging issues. And there's a bug ( Yes Torley. The quickest way to reproduce it appears to be to be as simple as triggering one sound after the other and to observe the client's behavior. As it appears to be random, it can happen very quickly or take several attempts.
On another note, I disabled sound queueing in one of my sound objects that plays 13 clips in a long loop. Dumped cache and logged back in. Sounds began to download one at a time. After about 5 clips were transferred, the 6th and 7th clips received the BOOM, ABORT TRANSFER error... Clips 8 through 13 completed as normal. I can send you (or anyone else) a copy of the object so you can try this out for yourself. Does not appear to be completely tied to Sound Queueing. (at least from what I can tell) I am asking Moopf Murray to confirm that his vendors do or do not use llSoundQueueing as well. Just wanted to comment that I've seen this too. Not often, but every now and then.
I have an example of that now rezzed in Duvillier. The sample was uploaded less than 12 hours ago. It is not working anymore.
If anyone wants to have a look it will probably be there for 36 hours. Just IM me for a tp. Thanks Hastur, Rita, and Huns.
Rita and I unfortunately weren't able to repro it there, but I headed next to Hastur's place @ Chebi (83, 82, 96), where I proceeded to stand in front of "AA Vendor - Science Fiction" and click the "Preview Sound" button once, then press the "Next" arrow. I indeed encountered the same errors in the log, where sound files wouldn't play:
And I should also note I cleared cache before doing this.
I managed to get this info while playing with the object we previosly looked at with Torley. I had 3 similar objects, playing with different sounds. Each time I started SL one or two of them didn't play. Each time the cache was cleared.
INFO: LLAudioEngine::startNextTransfer: Getting asset data for: e8af4a28-aa83-43
Sunday 4/29 between 1pm - 3pm. Online users reached about 39,000+. Aborted sound transfers very frequently during this timeframe. Was working on an object that contains 6 back to back clips. Every clip encountered the Boom, Abort Transfer error. Dumped cache, rebooted PC, logged back in. Now clips 1,2,4,5 & 6 transferred OK, but clip #3 got the same error again.
As a suggestion, this problem would be completely bypassed if the SL client did not insert dead silence for the aborted sound clip. If the client re-queried the sound clip asset ID and then redownloaded the sound clip, everything would fall into place. So if the clip wasn't successfully cached the first time, when it is called upon another time, the client tries to retrieve it correctly. As stated earlier, right now the client inserts dead silence for the aborted clips... and it remains that way until the cache is dumped. Client should keep requesting preloaded sounds until they actually get downloaded!
1/2 to 3/4 of the samples in every sample sets that I upload or uploaded in SL still don't play...
Did you found the cause of the problem at least? Any news? Is Hastur's suggestion difficult to implement or bad? Is it true that sounds have lower priority than textures in downloads? Thanks! I'm noticing the several patterns in some recent testing
The work-in progress can be found at (109,115,301) Aroha Island - an internal testing area. Upon arriving, face East to see a white board which will reproduce the issues. The board has 7 lines of text, that when clicked play their corresponding sound sample, those seven are preloaded. Next/Prev buttons preload a different set of seven samples. As of yet, I'm not sure if there are any issues with double-Preloading - if anything it seems to be helpful, as noted later. The behaviors are somewhat erratic. These typically occur only on a 1 or 2 sample-prims or sometimes not at all. Continued attempts will reproduce the bugs. Also, use of the Prev/Next starts a re-Preload cycle that may resolve issues or create new ones. I classify the behaviors as: Never-Play:
Double-Play: Triple-Play:
Random-Play:
There is a bug in my object that the last 'page' is sent the duty to Preload and later play a null-key. I have a fix for this, but SL's been laggy today, and it doesn't really affect the issue at hand. Relevant Code: } Hmmm... it seems there has been progress made on this issue. Not completely, but I'm seeing more of the "Could not load data" vs. error flood.
I've mitigated some of the problems by changing my object to have a single central script solely responsible for loading and playing sounds. Whether by LL's work or my changes, I now frequently get the 'Playing without a channelID", in Never-Play scenarios. What are these caused by, and how might we mitigate the risk of these happening. Also I'm getting more "could not load" now, which I don't remember getting before. ~~~~~~~~~~~~~~~~~~~~~~~~~~ @Rob Kubrick: Thanks for doing such extensive testing, I'll check with our devs on this.
Can we get an update on the possibility of adding some redundancy into the SL client to re-cue aborted sound clips and to stop inserting 10 seconds of dead silence? We've been piling on the votes of residents that have been impacted by this particular bug. We've seen about 3 new client updates roll out and
I'll ask about that, Hastur.
This problem definitely still exists... however, I've made an interesting discovery. It is true that llTriggerSound works more reliably that llPlaySound. It has also been noted that the llPlaySound problems go away once you play the sound at least one time.
What I have been able to do successfully, so far at least, is to call a nearly silent (volume = .001) llTriggerSound just before calling llPlaySound, and it seems to make the llPlaySound function more reliabily. I also loop through my set of sounds calling a preload on them, and then a nearly silent TriggerSound on the previously pre-loaded sound clip. Perhaps this is causing/forcing/ensuring a Preload state for the sound? These are all obviously hacks and voodoo, but I figured they might be helpful for devs out there and for determing what the underlying issue is. reply to Nat >
This is great information and I can confirm that llTriggerSound does have a more reliable playback performance as you've detailed. However, the core issue for this ticket is that the sound data downloads are occasionally aborted and leave a "10 seconds of silence" ghost cache and will never attempt to redownload correctly. As a side note (and will enter a new JIRA ticket on this if there is not already one out there) using a single llPlaySound can very often result in a "Aborting on Channel 0" type message that can be seen in the debug console. As Nat points out, that if the sound clip is queued up a 2nd or 3rd time, it will eventually play correctly. While you can script out several alternative methods to force guarantee the sound plays back correctly for you on the first attempt, it does illustrate an underlying problem that needs to be fixed. DEVs> How about an update on this ticket? It has over 100 votes from residents, marked as urgent and in progress, but went from "workingonitlinden" to Unassigned for several months. reading about that comment from Hastu abour the corrupted cache entries, I decided to create this entry http://jira.secondlife.com/browse/VWR-3095
This was stalled for a while. Work has begun again and it should be fixed in an upcoming release. Hope this helps.
This is still not fixed.
I just read the recent comments and I had already converted to LLTriggerSound. I just flew my tour (with audio commentary) after a break of over a month, and only 3 of the 9 sounds played. This weekend has shown just horrid asset server performance. Combined with this unresolved bug, there has been an average of 90% failure on sound clip data.
Both Friday evening (6pm PST) and again Sunday morning (starting around 10am PST).... consistently 8 out of 10 triggered sound clips receive the BOOM ABORT TRANSFER and other transfer errors. Of course, heavy concurrent online residents above 50K at both times. It's absolutely ridiculous that this bug still isn't fixed about one year since it was reported first. 2 out of 10 sounds didn't play correctly sunday evening - no matter if they are triggered by script or manually with "play inworld" or "play localy". I'm curious if this thing will ever work within this MILLENNIUM!
Perhaps it's time for sound files to switch to the TCP download path?
Sunday afternoon @ 4pm PST. 63,000+ people online. Asset servers are again aborting sound clip data transfers.
Hastur, I don't think it has anything to do with the amount of ppl online, just that fact that the server is incapable of processing the required requests. My clock chimes are borked, my piano sheet music won't play, my music box renditions just laugh at me. The server just cannot handle sound file requests, and puts them to the bottom priority, period. No one gives a shit. They think it is a Havock 4 thingy. it is not. A bunch of problems with Windlight have been ignored, and now it will be in the standard viewer. Boy are there gonna be a lot of complaints. I have given up on doing the jira crap. Why bother. About .2% of us are involved, and LL thinks only .2% have problems. Wait till the next release. I feel sorry for the ppl at LL. you have a big mess to clean up. Done with you "Jira" you don't care, I won't waste my time reporting problems anymore.
Simple math, just calculate, the number of ppl reporting problems in the jira, with the number of ppl online, and you will come up with a small amount of ppl having problems. The accountants will love you. Hehehe, just wait, you are in for a big surprise! I am done with the Jira thing! It is pointless and a waste of my time and anyone that is assigned to it to the Jira, to resolve any problems because the numbers in your opinion don't add up. I don't see me spending my monthly tier much longer! Will probably quit Sl. I had several complaints of my customers this weekend about sounds not playing correctly. It's distressing to tell them all the time that it's a Linden issue that isn't fixed for about one year now.
I can confirm this is still going on. I have a script that used llTriggerSound and changed these call to llPlaySound with llSetSoundQueueing(TRUE). It seems that every other sound would not play, ie first sound would play, second sound wouldn't, third sound would play, etc.
I have to agree with Joshua, one year and still not fixed. It's a good reason why I only make things for myself as the content is continually breaking. I would love to be able to sell my objects, but I can't imagine the headaches. I got several complaints from my customers the last few days. Did this problem increase?
It seems that LL tend to just "forget" issues they don't find a solution. The last post by a linden was on 17/Dec/07 09:29 PM... last year!!! Does anyone of them still care about this problem? It would be interesting for all of us to know if there is any progress! It's the same with http://jira.secondlife.com/browse/VWR-7779 About 80% of my sounds aren't loaded today. IT SUCKS!!!!!
Changed this to Critical to point out that this needs to be fixed asap. Also changed affected version to 1.21.
The beauty of this ever growing Second Life is in the details we create and sound is indeed one of the most important details that add realism & beauty .
What if texture only came in Black and white ? Not exciting is it ( the thought ) If we could only see birds but not hear their song they become pictures . When I sit at a piano ,I am not resting my feet ..I am there to play/hear something wonderful otherwise it becomes just a pretty prim or picture . We need the sound to be equally as important as texture ..Both make SL the special place it is . This is an extremely critical bug. Nothing breaks the illusion of immersion in SL like having a sound glitch (or a graphics glitch for that matter). Sounds create the "space" we feel. It all collapses when this bug hits. Please, up the priority! Thanks.
This is definitely a deal breaker for us for our Christmas display. We are noticing NUMEROUS sound glitches this year that didn't appear last year, and it's going to negatively impact our sales this holiday season. PLEASE, Lindens, let's get this one fixed!
I'm active in theater projects iSL - having unreliable sound fx severely detracts from the audience's and actors' experiences. We are wired to hear sound lag and other errors more acutely than we see visual lag, and to hear as "wrong" smaller errors than the ones we see. Sound quality in SL should be a much higher priority than it is.
I try to make a nice place and sound really is a big part of the ambiance. Hope it will be fixed soon because it makes my place a more special place for me and my love.
i live in a bubble and 2L is my only life.
i live in a bubble and 2L is my only life.
Just posting to confirm that this issue still exists. Any progress?
2008-11-18T21:58:28Z INFO: assetCallback: Boom, error in audio file transfer: Asset request: failed (-1)
2008-11-18T21:58:28Z INFO: startNextTransfer: Getting asset data for: 79672ddd-17db-454b-b3cc-b916c4f7c872 2008-11-18T21:58:28Z INFO: _queueDataRequest: Starting transfer for 79672ddd-17db-454b-b3cc-b916c4f7c872 Also lots of this sort of thing: 2008-11-18T21:58:28Z INFO: startNextTransfer: Getting asset data for: 79672ddd-17db-454b-b3cc-b916c4f7c872 Then later, something along the lines of: 2008-11-18T21:58:28Z INFO: abortTransfer: LLTransferTarget::Aborting transfer 3aed8e88-5243-6827-de13-24e0c045bfd2 from 216.82.21.236:12035 This is a showstopper for synchronized playing of audio loops. ;_; Any advice in regard to workarounds or progress on fixing this issue would be appreciated. Incidentally, I've tried TriggerSound, PlaySound, preloading everything before starting, preloading one ahead while the current clip is playing, not preloading at all, and it all borks out after a while. It seems to work when I first log in, then breaks. And works for a little longer if I obtain a new IP address, then breaks.
System information, if it matters: Second Life 1.21.5 (98701) Oct 6 2008 10:39:11 (Second Life Release Candidate) I use sounds a fair amount in my building. I need them to be reliable.
It's challenging enough to build good ambient sound sequences without struggling with upload issues and finding gaps. This should be fixed already!!
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 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.
All the OS clients got this problems..I run Linux and XP ...there is the same problem...sounds sometime vanish..as a ghosts...so what can I say..is really impossible that Linden's don't look for a final solution..
 ( The cooperative sim I belong to is often visited. It's a forest environment and sounds/ambience are an integral part of it. Please address these issues as a priority.
PLEASE FIX THIS~Sound-scaping is an essential part of creating role-play atmosphere!
I've ran into this issue recently, but was having some problems reproducing the results consistently. Some sounds were being downloaded reliably, some were not. After some sorting through the sounds I was using I noticed the following:
This is easy to repro. Upload some sounds and hear them playback reliably (and when they don't note the correct transfer error on the logs). Now try playing some old sounds (I only had sounds dating back to 2005 to test the old sound problem, so I'm not sure what exactly qualifies as an old sound, but I know those do) and see the problem appearing and no mention of error transfers in the logs (apart from the FMOD abort error). You can use these sounds to test the old sound problem (uploaded in 2005): And these to test with new sounds (uploaded couple of days ago): Testing environment (note that I am using the CORRECT fmod library 3.75 even though the current SL viewer available for download has the INCORRECT 3.74 library. Problem displays equally on both FMOD libraries): Second Life 1.22.11 (113976) Mar 6 2009 16:05:03 (Second Life Release Candidate) You are at 258414.0, 262102.7, 401.1 in Maia located at sim7752.agni.lindenlab.com (216.82.35.245:13001) CPU: Intel Pentium 4 (Unknown model) (3727 MHz) libcurl Version: libcurl/7.16.4 OpenSSL/0.9.7c zlib/1.2.3 Hear hear! Would like to see this fixed.
I stand in an environment I have created & it is silent but for SL's background noise. I add sound effects & the place comes alive. When the sound doesn't work, my experience & the experiences of those who visit places I have built are impacted. sl is full of beautiful gardens and landscapes. sl is all about being submersed in a virtual world. In the is world we cant "touch" or "smell" but we can see and hear. Therefore, to back up seeing these amazingly created places, why cant we fix the problems that would fully immerse us in these places by fixing the sounds that would give the creations the recognition they deserve
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
In Progress
Critical
Sound files often are not downloaded
