|
|
|
I agree with Hastur 100%. Whilst this work around may make this functional ( just ) the impact on performance and user experience isn't satisfactory and surely delivers a performance hit on the rezzing of all the environment, not just sounds, as it forces the consumption of unnecessary bandwidth. Really hope the sound system can get looked at with urgency soon, its a critical aspect of immersion.
In the environments I create, with many sounds, this introduces a very disagreeable delay. Please up the priority for a real fix!
The section of code handling this in the viewer is in
bool LLAppViewer::cleanup() in llappviewer.cpp. It specifically deletes these filetypes on cleanup: // delete some of the files left around in the cache. However, this is important: According to http://jira.secondlife.com/browse/VWR-2876 The viewer just has to place the encrypted .ogg files from the cache into the VFS cache on relog, and convert them into .ogg once more, which is what's causing the delay in sounds initially. On further note, perhaps the switch to OpenAL can make use of .wav files directly, removing one of the most HDD intensive and time consuming steps here? (P.S. sorry for the many edits, I'm out of it today. Also fancy markup!) The waiting time is a nuisance, but the increased downloads are costing real money for people who are metered by GB on their broadband connection. This even may cause people to leave SL!
Ditto on all of the above. The delay is something that most casual users won't understand and/or tolerate before moving on. We depend on the spontanaeity of being able to hear the sounds in our products immediately. Come on Linden guru--let's make this a critical issue that needs immediate attention!
By the way, I removed the deletion of .wav, .lso and .dsf according to Henri Beauchamp's patch in
However, the result is an increased disk space usage, naturally. Let me explain: The uncompressed sounds already can and will take more space combined with a filled cache than what you specify as cachespace in the viewer (I run my cache in a 1gb ramdisk, with cache set to 512mb). This is necessary, as there is just additional space needed to decompress/convert those things and keep em alive during the viewer session. Before, my cache usage + vfs used to go to about 700mb in a couple of weeks in the ramdisk. However, with the patch applied, as a result the disk space used with a 512mb cache (in my case) will easily blow 1gb in one or two days. Expect to have lots of hdd space ready if the sounds are kept. Annoying to wait for reload.
i hope it will be fixed soon
i live in a bubble and 2L is my only life.
I use sounds a fair amount in my building. I need them to be reliable.
I realize there are plenty of things to be fixed but a patchy and unwieldy fix that requires waits and workarounds is not customer-oriented.
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.
...bbbooooooooo...òò
is really impossible that after a long time nobody of linden's take care about this problem The full homestead sim that I've created uses sounds to complete the aural picture. Please take care of these issues soon.
How about a status update? This still needs fixed!
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Normal
RC13 deletes sound cache after quit
Dumping the sound assets on every exit is not the way to go. This causes a huge amount of extra downloads, database queries, and client side issues that are completely unnecessary.
Sound assets should remain in cache and be managed by the client side cache settings. The priority of this issue should be raised to the same urgency as VWR-291 as this is not an acceptable client behavior or quasi-fix for the main issue that has not been resolved since May 2007.