[BUG 1140853] Open Rails goes mute, sound is stripped from sim VERY quickly with tile loads/reloads

[twpol]

Imported from https://bugs.launchpad.net/bugs/1140853

Property	Value
Reported by	Eldorado Railroad (eldorado-railroad)
Date reported	Sat, 02 Mar 2013 22:55:37 GMT
Tags	performance, sounds

This is an bug that has not been addressed when I first brought it up a few years ago at Elvas Tower. The fallout from this persistent bug has been made worse since the release of the new signalling system. This bug report is with OR x1468. Older versions of OR eg(X1392) still have this bug, but take a long time to have an effect on sound.

Memory management has been poor for consists (ie shapes and their related data such as textures/sounds, etc), but has not been a "show stopper" until the signalling system was changed.

The memory management problem occurs when the consist spans TWO world tiles. This means the front and the back of the train reside on different tiles. The more items there are per tile, the faster the effects of this bug will appear.

To replicate this bug, a consist of some length X must span two world tiles. By quickly switching (numerous times, maybe 20 or less) between the front and back (camera #2 and #3) of the consist a reload of the world tile is triggered. The more shapes that are required to be reloaded the greater the delay occurs in reloading, and can be seen in the Debug HUD with the Loader process going from 0% upto 100%. Eventually the Loader process value returns to 0% once either the #2 or #3 has been chosen. This type of camera switching will often occur in switching/shunting yard work.

The "innocent" victim in this process of loading/reloading is sound. In the Debug HUD, its values goes from 0% to 1%..2%..3%...but never recovers. Eventually you may receive a "Warning: Sound stream activation failed at number 768" in the runactivy.exe CMD box, but that is not always going to happen. But regardless if the warning message appears, when the Debug HUD displays 3-4% for the Sound process and stays there the sim becomes mute...silent. It is as if the number of sound slots have run out in OpenAl, and the sim is waiting for a resource that never returns. Once the mute sets in, the user will NEVER recover sound, regardless of how many camera switches or world tile movements occur. Not only is the consist silent, but so are crossing gates, etc.

This has been tested on multiple routes. The key to replication of the bug is to have a consist that spans TWO tiles and the more shapes per tile the faster the error will occur.

In general, I do not understand why the player consist is not left in memory, even if it is out of view by having travelled with the free roam camera. From what I can see in the Debug HUD it is not part of the managed memory, and if the camera travels far enough from a long and varied consist (ie 100 Mb or more) there is a very long delay in reloading all of the shapes, texture, sounds, etc. Now there also seems to be the problem of sound slots running out upon each reload.

Eldorado

[twpol]

Imported from https://bugs.launchpad.net/or/+bug/1140853/comments/1

Property	Value
Posted by	cjakeman (cjakeman)
Date posted	Sun, 03 Mar 2013 16:00:14 GMT

Hi Eldorado,

Looks like you've done a lot of anylisi on this and it must be frustrating to see this symptom getting worse as new releases are made.

What route, location and consist would you recommend so that we can see (or perhaps fail to hear) it for ourselves?

Thanks,

Chris

[twpol]

Imported from https://bugs.launchpad.net/or/+bug/1140853/comments/2

Property	Value
Posted by	Lindsay Spellman (zlinw)
Date posted	Wed, 06 Mar 2013 21:21:13 GMT

I have had what I assume is the same error the error message being identical "Warning: Sound stream activation failed at number 768". The error occurs on both routes I regularly use "VR North East Mainline beta" and "Footscray Ballarat full". Unfortunately neither of the versions of these routes I use are availible on the net at the moment

For me the error is produced by switching from the "1" view to the "2" view, I have found it not particularly difficult to produce, unfortunately..

I will see if I can get it to occur on a route that is easy to get hold of.

Lindsay

[twpol]

Imported from https://bugs.launchpad.net/or/+bug/1140853/comments/3

Property	Value
Posted by	Eldorado Railroad (eldorado-railroad)
Date posted	Wed, 13 Mar 2013 15:25:41 GMT

Chris,

Sorry for the delay in response, very busy time of the year for me, even during this "March Break" in North America!

As explained in the original post:

"To replicate this bug, a consist of some length X must span two world tiles. By quickly switching (numerous times, maybe 20 or less) between the front and back (camera #2 and #3) of the consist a reload of the world tile is triggered. The more shapes that are required to be reloaded the greater the delay occurs in reloading, and can be seen in the Debug HUD with the Loader process going from 0% upto 100%. Eventually the Loader process value returns to 0% once either the #2 or #3 has been chosen. This type of camera switching will often occur in switching/shunting yard work."

The consist can be anything that is long enough, and the more variation there is in the consist (NO DUPLICATES) the faster it will occur. The consists I use are a mostly a multitude of payware from numerous companies. Implicitly, shape files, textures, and sounds are different for each engine/car/wagon.

The route where the bug was discovered is a "freeware" route entitled "MSTS Route--NS Alabama Division Birmingham". I often use this route for testing OR because it is exceptional for resource requirements. It is available at www.trainsim.com with required files: bham1.zip bham2.zip bham3.zip birminghamupdatev2.zip

The path used in this route which triggers this problem is entitled "Around the Loop AI 1.pat".

It is most important to stress that the front and back of the consist MUST be on separate tiles, eg: -11439 13952 (Front, Camera #2), -11440 13951 (Back, Camera #3) For the above tile numbers a consist of 70 units was used.

Please note the connection with this bug: https://bugs.launchpad.net/or/+bug/1140934 , which thus far has not been addressed by anyone as of this writing.

Eldorado

[twpol]

Imported from https://bugs.launchpad.net/or/+bug/1140853/comments/4

Property	Value
Posted by	Peter Gulyas (pzgulyas)
Date posted	Wed, 08 May 2013 18:26:27 GMT

I found a bug in sound subsystem where none of the environment sounds got removed from memory, and this caused the number of active sound streams to reach a limit (in my case it is only 256, not 768). I will also (try to) prevent sound streams of camera-attached train unloading from memory. I will submit a patch latest the next week.

This patch will be a part of a bigger modification, where I started to move the "listener" position along with camera for having doppler effect also for environment sounds, like the level crossings. I also modified the sound volume handling code to match the MSTS "standard", which was not the case till now.

But some testing is needed before submitting the patch to check if everything works correctly. (Will not, of course, but trying to lower the chance. :-) )

[twpol]

Imported from https://bugs.launchpad.net/or/+bug/1140853/comments/5

Property	Value
Posted by	Peter Gulyas (pzgulyas)
Date posted	Thu, 16 May 2013 06:36:20 GMT

Fixed in r1604.

Reaching the maximum number of sound streams OpenAL can handle theoretically is still possible, but it will not lead to a complete mute forever. The number is 768 for most people, but as I understood, it will be possible to increase this number by using the opensource "OpenAL Soft" dll instead of the Creative Labs's one currently used, by recompiling that with a higher number for allocation. I need to investigate this further.