- Status Closed
- Percent Complete
- Task Type Bug Report
- Category Engine → Sound
-
Assigned To
Mathias - Operating System
- Severity High
- Priority
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#3929 - mad lag in some areas due to sound
after the update to 0.5.1 i’ve started getting some severe lag in areas like inner lannx temple, almost all of the sewers and also when i enterd i think lower bronze doors.
note the lag hits instantly i step into the inner parts of the temple and i mean instantly every time.
the lag does NOT let go even if you load a new area or say sit down for awhile, only way to get rid of it is to actually shut down the client and open again, this was never a issue with 0.5.0… well when it came out it was but not with the final 0.5.0 updates.
ojaveda has some lag also but nothing severe like the one in the other places, the road maps are okay and hydlaa is more than okay talk about fps atm except when you look from the forrest towards hydlaa, it’s like looking throu all the walls and houses but this one is easy fixed, just look down the others that don’t even work.
sys info if need be
windows xp sp3
pentium 4 HT 3.2GHz
2gb ram
geforce 7800gs 256mb
note this setup has worked just fine untill 0.5.1 and also i ones uninstalled and reinstalled 0.5.0 then ran –console to update that didn’t work and now when i have the 0.5.1 install i used that… same thing
| ID | Project | Summary | Priority | Severity | Assigned To | Progress | |
|---|---|---|---|---|---|---|---|
| 3421 | PlaneShift | Medium | Mathias | ||||
| 4369 | PlaneShift | FS#4369 - Sound Bugs Effects/Spells/Etc | Medium | Mathias |
19.04.2010 21:08
Reason for closing:
Additional comments about closing:
Fixed by Agy and botanic
Confirming, the lag also increases after multiple traveling between maps.
My opinion is that it can be caused by compressed shadercache file instead of previous using of directory. Maybe using uncompressed shadercache would help. Is there option to change back to previous shadercache directory or setting compression level for shadercache file, eventually turning compression completely off? Using compression for dialogs can be without problems, but when there is need for uncompressing every time the shader is used and the processor is used at 100% already, it can only cause lags while waiting for the shader is extracted. It’s only my opinion but I didn’t find anything else changed too much to cause this issue. Another option could be that the actually used shaders should be stored uncompressed in memory including list of shaders stored in shadercache and loading/saving them from/into shadercache file should be realized only while traveling between maps (map loading screen), which could cause waiting only in the map loading screen and that is not big issue, instead of it waiting while running from mad maulbernaut is in 90% ending in Death realm without even chance to do something against it.
Strange, I get no lag in the areas described (not tested BD yet), and my setup is having severe issues with shaders already (so much that I set them to lowest to make loading and especially freeze-times slightly bearable).
Even at this setting, the shadercache is used, as can be seen both from the console, from the minute-long freezes when shading something never shaded before (could it please be made an option to pre-shade everything from inside the launcher instead of on the fly? Loading “in the background” (even when disabled completely in pslaunch and the config file) is annoying enough already without shading times added to it) and looking at the changing file size of the shadercache file itself.
I agree about the fighting issue: I pretty often get multisecond-freezes right after initiating combat, which is pretty much the precise time when it is most undesirable.
My system is Win2000 on an Athlon64 3800+ with Radeon X800XL, 2GB RAM and pretty slow disk drives.
update:
now also the winch cases some of this unending lag also noticed that if i go into the inner part of the temple after this i can bearly move… problerly under 5fps or less.
also to add, that when the lag hits the game loads VERY slowly between maps.
update: my lag is caused by openal, when either turning off sound completely or setting it to software i get the frames back and no lag, though setting it to software i then don’t have sound at all and that’s allready reported by me HERE
0.5.1 increased my lag, too. I had been online with 0.5. only days before and though it was laggy compared to 0.4, I could move. Now I have lag to the extent of the client freezing and having to be closed, no regular exit possible as it just doesn’t react.
Just standing in Hydlaa, right in front of one of the houses close to the tavern so only a bit of ground and the front of a house was visible, I could not even reach the chat window half the time as load on my computer was so crazy, just clicking anywhere on the PS window seemed to stall the client all over again. I could see my guildmates trying to talk to me and I could hardly reply when I wasn’t even trying to move. When I walk I get stalled every couple of steps. I won’t even try to do anything else like fight or cast magic with this lag.
I have shaders set to lowest, graphics to medium, sound is off, background loading is off. As I said, this worked with 0.5. It doesn’t any longer.
please assign to me, also seems to be related to when you have an emitter at a sector line it makes that spot lag. Alt+Tab (making audio bug out and stop playing) makes the lag stop.
Ok did some tests, the problem is with too many emitters, laanx has a ton of emitters overlapping, removed some and elvi had a lot less lag. Whoever set MAX_RANGE=”12.0” so that it stretches over the entire area is the culprit!
replace npcroom1.xml in world/sounds with this one and you will feel the lag :)
http://pastebin.com/f5b7d2832
Nice to see you can cause lag, but can you also remove it without causing other problems? :)
Assigning to Botanic.
no change with the 0.5.1.1 update.
these are the areas i know causes this “sound lag”, so here are /pos for them like you asked botanic.
swr-orange 5.95 -5.95 -146.06 seems to start at this junction.
laanxmain -0.10 -0.00 -6.45 starts in the archway.
bdoorsout 44.05 -278.16 -2671.81 the whole area.
bdoorsin -112.50 -175.50 -1495.46 gets worse here also the whole area.
this one seems to cause a litle but nothing like the above.
hydlaa_winch 40.71 -0.04 -209.03
and i bet these plases arn’t the only ones.
also noted that when going into some of these areas the sound cuts completely
I think botanic found the reason (too many emitters or something). Hopefully he can fix this easily.
Ya the problem is that all sounds are loaded on entering an area. Also some sound cards only support 16 or so channels so if 17 sounds are playing the lag will become pretty bad, dont quite know how we can fix this other then removing a lot of sounds. The way it SHOULD be fixed is in the engine… but ya…
In a way that makes sounds which are either not playing ATM or not in hearing range not occupy a channel? I’d assume that merely loading a sound would not affect lag, anyway, but then it’d have to negotiate / set up a channel whenever it wants to start playing. Not sure if that’s that much of an operation to cause noticable delays, though, which would be annoying when the sounds are supposed to be related to your actions.
However, I wonder why this never was a problem before, given that the engine used to be less capable and the sound being rendered by software only (presumably hardware rendering would speed things up, right?), etc.? Is it a flaw of OpenAL that whenever it runs out of hardware channels it becomes hideously inefficient? That’d be a major design flaw IMO (one that’d make me ditch the whole thing immediately, in fact, especially since it’s advantage over SW sound actually isn’t apparent to me at all).
The reason it wasnt a problem before was not because we used software, they both have the same channel issue, the problem started when we added emitters for things like torches. There were almost no ambient sounds before so the 16 channels were never all used.
this lag is getting worse and worse with each update, some areas get beter but now it’s caused on bd road and oja road also… maybe it’s time to add a option like how many sounds can play at ones, i really hate to run this game without sound as it adds to the athmosphere but in the current situation the game runs so slowly it’s just and just bearable.
if you don’t have a decent audio card i’d suggest installing openalsoft. creative audio cards supports at least a minimum of 64 channels on usb/laptop solutions and 128 on pci-e solutions
Infos for testers on this one:
soundlib.zip already contains a special xml for NPCroom3.
This xml has 200 emitters defined which have a distance of 5 to each other (like a minefield :)
NPCroom3 -114 -0 -59 will teleport you directly into it.
200 Emitters is a worse case scenario because bronzedoors (in and out together) have 73 of em.
Your framerate/lag should normalize when leaving that grid. If it does not: please report
The lag your may experience within the grid is a maximum of 15-20 emitters (sounds) playing at the same time.
On bronzedoors there were ~35 of them playing at the same time (old code).
I do not have exact numbers but i would be surprised when they would go over 5 (new code).
About laanx .. go into the temple and walk around. Maximum number of sounds playing there is around eight.
Happy testing!
Many cards have only 16 or 32 sound channels and unfortunately also these in notebooks which can’t be replaced by something else.
Im aware of that problem, However current svn doesnt exceed 16 anymore.
And im already working on a solution to limit the number of used channels.
Ran around the location in npcroom3. Lots of crackling noises :) moving in stereo when moving around. Movement was sometimes a bit choppy, just like typing now in here is :). Taking into account the 50 npcs standing around there, even in the middle of the sound movement was OK and not worse then when I moved away from the sound. Also no weird behaviour of used memory. I consider this fixed.