[hugoakio]

I'm using Monogame Rev 99.1, and with long trains, 2300m of lenght, with modern diesel locomotives at the rear end the engine sound are "restarted" (the diesel engine sound starts from the lowest rpm to the actual notch rpm) every time when I press "3" key. After this, If I press the "2" key the same problem occurs in the leading locomotive.
Here's my train: 2 AC4400 + 40 cars + 1 AC4000 + 80 cars + 1 AC4400

[engmod]

I don't have that problem with 99.1 here.
I have not tested with an ac4400 though.

Does that happen with other loco's?

[ErickC]

The SMS is unloading at the head end and loading again when you switch views. The idle sound is probably configured as a cued loop with startup and shutdown sounds in it, so it plays from the beginning every time the SMS loads again.

One of the problems with OR is it basically disregards the activation/deactivation distance parameters above a certain distance, so the SMS will deactivate at 2,000m regardless of where the activate/deactivate distance is actually set. I wish it would just do what we told it to do like MSTS did. One thing I suspect is related is that the sim doesn't seem to understand how distance works. Run the sound test window with an SMS that deactivates at a long distance and you will see some very funny distance numbers around the 2,000m mark. The distance jumps from 2,000m to 2,800m instantly.

These distances might seem unreasonably long, but we're talking train lengths that have been normal in North America for 40 years. You should still be able to hear the locomotives at the tail end of a mile-long freight train - if you don't believe me, I have recordings.

So your SMS is deactivating causing all of the initial loadup sounds to play because the tail end of the train is past the arbitrary point where OR has decided it will not load an SMS. I think it should be extended to 10,000m since that's the maximum viewing distance. Let us sound developers decide when clips spawn in, we are perfectly capable of optimization.

[Csantucci]

Things are a bit more complex and a bit different.
As far as I see from the code, it is not the sound code that decides to stop playing a car sound when the car is beyond a certain distance; it is the fact that the train cars are unloaded (no more visible) when they are at a distance from the camera that is higher than 1.5 the viewing distance, as defined in the OR options.
So, if the train is longer than the viewing distance, the last cars won't play when we are near the locomotive and vice-versa, with an exception: the player locomotive is never unloaded from memory, and therefore its sounds remain active (if the case requires it with volume = 0), independently from the distance of the player locomotive from the camera.
There is another parameter which must be taken into account, which is the max allowed number of active sound sources for the open source sound library that OR uses, that is OpenAl. This number can be modified (increased/decreased) in file alsoft.ini, that resides in Users/Myself/AppData/Roaming.
So I'd say that, setting Activation and Deactivation distances longer than the train length, setting a viewing distance longer than the train lenght, and having a suitable max allowed number of open sound sources, the sounds shouldn't be restarted when switching from camera 2 to camera 3.
I wasn't able to reproduce abrupt increases of distance in the Sound debug window when the distance passes 2000 meters.
The only strange point I noticed is that, when passing the distance of 2000 meters, the string of a playing sound in the Sound debug window passes from "Playing Loop" to "New Loop". But here maybe the author or the code of the sound debug window may provide an answer.

And last but not least OR does a thing much more realistically tnan MSTS. In MSTS, when there are e.g. more cars that are playing the same looped sound, there is only istance of the sound playing, like a single-voice chorale. In OR instead each car plays its own looped sound, which, as in real world, is not in phase with the other ones.

[ErickC]

The problem with that is that my view distance is set to 5,000m, the SMS activation/deactivation distances are set to 10,000m, and the train is still in view when the streams all unload. Also, from experience, I know the limit on streams is 1024 - which is why I had to very carefully re-tool my freight car sounds because I was originally hitting that limit. Now I don't come anywhere near it, so that's not it, either. As an example, this is the tail end of a 105 car unit coal train with 5 SD40s on the point:



You can see we're nowhere near the limits because the freight car sounds use per-stream volume curves to handle close, medium, and distant audio, with streams deactivating when they reach the distance where the volume is zero. This means that this mile-long train isn't anywhere near the limits. The next shot shows the tail end of the train from a static camera at 1,999 meters from the lead unit:



Here the train is just a few seconds later. The moment the 2,000 meter threshold is crossed, the "distance" becomes completely arbitrary:



Note that all of the streams at the head end of the train are deactivated. This is despite the 10,000m activation distance set in the SMS file. The distant streams have no deactivation distances set, unlike the close and medium distance streams. There is absolutely no reason these streams should be deactivated. And the entire train is well within view:



And I know the player locmotive's streams all deactivated. This is easy to test. If I go to the rear of the train, hold down the spacebar, and switch to the #2 camera, the horn is mid-blast indicating that the loop started when it was commanded. However, if I return to the fixed camera from where these shots were taken, and perform the same test, the horn loop starts at the beginning of the wave file, indicating that the SMS loaded when I switched views.

The code might say one thing, but it's doing another thing entirely. I speculate that OR either ignores any SMS activation distance beyond 2,000m, or, because these SMS files are all still "active," deactivates all streams at 2,000m regardless of what the global activation distance for the SMS is.

[hugoakio]

Seems like a distance issue. I made several changes as CSantucci said, and the problem persists. Also I made the same consist reducing 40 cars and i had no problem with the sound.

[Csantucci]

I've looked better at the code. Strangely enough, it does not seem to correspond to the tests I did.
It seems true, like Eric affirms, that sounds farther than 2000 meters are not activated in normal conditions, and become deactivated if they go beyond that distance. There are in the code some tests in case the activation distance and the deactivation distance are set to 0, but at first glance they don't seem to work so well.
I don't know if there is a way to easily improve the situation without drawbacks; I'll study a bit about this. Unfortunately I don't know well the rationales that were behind some decisions in writing this code.

[QJ-6811]

Another way is to better configure the .SMS file?

Use the Start up or down in combination with "Shift-Y" (diesel start up/down function)
IOW, when "switching" from front to rear locomotive, the SMS is "loaded again", but you immediately hear your diesel engine sound. (or am I misunderstanding the problem...?)

[ErickC]

 QJ-6811, on 19 June 2021 - 08:03 AM, said:

Another way is to better configure the .SMS file?

Use the Start up or down in combination with "Shift-Y" (diesel start up/down function)
IOW, when "switching" from front to rear locomotive, the SMS is "loaded again", but you immediately hear your diesel engine sound. (or am I misunderstanding the problem...?)

That's precisely what I am doing. Any real blending of the idle and startup or shutdown sounds will require one of two things:

1. Configure the RPM range in the ORTS Diesel Block to start from zero, then model the RPM range below idle and configure the startup and shutdown sounds to fade precisely as the idle sound fades in.

2. Use an idle clip that is a cued loop containing startup, idle, and shutdown, and configure the SMS so that it stops or starts looping based on the engine's running state. This is far simpler to implement. The main drawback is that any time the SMS unloads and loads again, the clip will start playing from the beginning. This is not a problem when switching views, because in this condition the loop starts from the first cue point instead of the beginning of the file.

 Csantucci, on 19 June 2021 - 12:08 AM, said:

I've looked better at the code. Strangely enough, it does not seem to correspond to the tests I did.
It seems true, like Eric affirms, that sounds farther than 2000 meters are not activated in normal conditions, and become deactivated if they go beyond that distance. There are in the code some tests in case the activation distance and the deactivation distance are set to 0, but at first glance they don't seem to work so well.
I don't know if there is a way to easily improve the situation without drawbacks; I'll study a bit about this. Unfortunately I don't know well the rationales that were behind some decisions in writing this code.

I had suspected something along those lines. It's always difficult when you're working on a project with this where code writers have come and gone over the years, so I definitely appreciate how difficult it can be to deal with sometimes and how it puts you in a tight spot.

I can definitely think of some performance drawbacks because a lot of SMS files are poorly optimized (I know a lot of mine were until I really started thinking hard about it and making tradeoffs for performance). Perhaps a compromise could be a way to flag an SMS file so that OR will use its parameters to set the activation? Then any SMS file without the flag could be treated as we treat them now.

[roeter]

 Csantucci, on 19 June 2021 - 12:08 AM, said:

It seems true, like Eric affirms, that sounds farther than 2000 meters are not activated in normal conditions, and become deactivated if they go beyond that distance.

The activation / deactivation range is based on the 'cutoff' range, that is the range at which the reduction of the volume is such that the volume has reached 0.
This makes sense as it is just a waste of capacity to keep soundstreams active if you don't hear them anymore anyway.
So any changes to the activation range has to be combined with a change to the 'cutoff' range (or better, the 'cutoff' range is the main parameter, activation range is derived from this). A fixed change to the cutoff range is not desirable, it could lead to problems on busy routes. Perhaps the cutoff range could be set up as a user or route variable.

 QJ-6811, on 19 June 2021 - 08:03 AM, said:

Another way is to better configure the .SMS file?

Use the Start up or down in combination with "Shift-Y" (diesel start up/down function)
IOW, when "switching" from front to rear locomotive, the SMS is "loaded again", but you immediately hear your diesel engine sound. (or am I misunderstanding the problem...?)

Presently, the engine sound is controlled by 'variable2', which is scaled between min-RPM and max-RPM.
Some years ago I introduced a test using a new 'variable4', which was scaled between 0 and max-RPM. The drawback of this was that all scaling values would have to be recalculated and all sms files altered accordingly. This was met by the community with a distinct lack of enthousiasm, and so the whole idea quietly went off stage through the back door.
However, somewhere on my list there still sits the (re)introduction of a 'variable 4', but set up such that the present values in the sms files can be retained, and the program itself calculates the proper scaling values between 0 and max-RPM, based on the defined 'variable 2' values and the min-RPM.
This would not only tackle the problem discussed here, but would also allow AI engines to be switched off and on, with proper sounds, e.g. when stabled in timetable pools.

Regards,
Rob Roeterdink