[Csantucci]

I wasn't able to reproduce the problem. Could you indicate a consist that causes the problem and where to download the related trainsets?

[BB25187]

Hi,

I come back to this issue. I can observe it with a recent version #1895, using at least two different engines.
The symptoms are similar to those described so far: the engine sounds in external views fade out when the activity has been run for a while (the sounds in the cab and passenger views remain correct). All types of sounds are impacted: initial triggered loops, play one shot, ... I noticed this issue with diesel engines. Maybe it happens with other types of engines and cars, but I did not check this.
I tried to back track the problem: it seems to appear with revision #1849, but in fact the first relevant revision which can be used for testing is #1853 (some bugs introduced with revision #1849 have been fixed in revisions #1851 and #1853). The problem is not exposed at revision #1847.
Providing a setup to reproduce is not obvious: for the activity under consideration, the problem appears after 15 to 20 minutes. But this duration does not seem fully systematic: this can take more time with other activities.
Three interesting observations though:
- The revision #1849 and higher expose another typical behavior: when the activity starts, the volume of engine sounds is first very (too) loud, and after a fraction of second, it reaches its expected value. Here again, the problem did not exist with revision #1847. Maybe the two problems are related, and this clue can be used to quickly identify if a revision is impacted or not.
- When the problem appears, saving/resuming the activity restores sounds with their expected volumes.
- On some engines, a sound is played once when activity starts (initial trigger + play one shot). Thus, it can be heard again when sounds are reinitialized during the activity. THis is not a problem in itself. But I noticed that the volume issue described above occurs only and systematically after such a reinitialization.
I hope it helps.

Regards

[gpz]

I heard this behavior already at very rare occasions, and I have an idea where in the code this might happen. The problem is that I cannot reproduce the error reliably. Sometimes it happens, but at the other 90% of cases the sound plays perfectly, even in the same circumstances. The most helpful thing would be to set up a test case where it happens always, or at least at most of the times. Till now I was unable to set up such an environment yet.

[markus_GE]

I think I have to add a few odd occurances to the above:

• I have just run a very (and by that I mean several hours) activity on the Gallup Sub by Bob Wirth, with a few 100+ car AIs passing by, and have experienced, in the external views (in-cab I might just have not heard it) that for some cars sounds were missing.
• These sounds, however, I then found along the route the AI had come, when I went through there: Without any reason suddenly the rumbling of an additional train started to fade in, got louder, and faded out again to completely disappear again. This accurred to me numerous times, and when switching to EOT view after the head end of my train had passed the location, I reencoutered the phenomenon at the exact same location.
• Switching to 4 view and not letting the whole train pass by can lead to the lead loco loosing its external sounds (no matter how long into the activity). However, this doesn´t "work" reliably.
• Also, not reliably, one can restore the lead unit´s sounds by switching to EOT view. If the train is long enough that the lead loco sounds go out of scope, they will be there again when switching to lead unit view again. Else, this doesn´t work (train too short).

This is what I noticed through two activities on different routes (Gallup Sub and Marias Pass 3.1).


Hope this helps a little.

Cheers, Markus

[Sid P.]

I have also remembered encountering this drop in exterior sound levels in past versions.
Today, I observed the behavior of X1897, on the Mactier route (I have also seen it on other routes) using a simple SLG activity. I recorded the approximate sound levels at the input to my audio mixer for view 1 (cab) and view 2 (front of loco):
------Startup and load activity: Approximate peak sound levels at input to local mixer:
View 1: -4 dB, View 2: -11 dB, Normal horn sound
-----About 20 minutes later:
View 1: -4 dB, View 2: -16 dB, No horn sound
-----Save and resume -
View 1: -4 dB, View 2: -11 dB, No horn sound
-----Shut down OR, restart and resume:
View 1: -4 dB, View 2: -11 dB, Normal horn sounds

I have observed the loss of horn sounds for exterior views occasionally in the past, but never took the time to document it. I have the impression that the behavior is not dependent on the route or the consist.

[dennisat]

I have experienced these strange sound behaviours occasionally and I have experimented with partially reverting some of the changes made in X1849. I think the update of sound position and velocity in TrainCar.cs introduced in X1849 can cause problems with serialization between threads which I believe is recognised in the code to interrogate the data in SoundSourceIDs from an intermediate array:

var soundSourceIDs = SoundSourceIDs.ToArray();
foreach (var soundSourceID in soundSourceIDs)
etc.

If you don't do this you get the occasional SystemException (I've proved this by interrogating SoundSourceIDs directly) because SoundSourceIDs is mainly updated in Sound.cs and that is in a different thread. I believe this could lead to occasional incorrect update of the Open AL buffers. I wish I could set up a test activity which always shows up the glitches but the fact that I and others can't leads me to believe this is most likely to be a thread serialization problem and therefore almost random.

I have moved the bulk of the code change in X1849 back to Sound.cs, including the new location normalization to camera tile, leaving only the calculation of Car velocity in TrainCar.cs because this is also now used in Cameras.cs. I don't seem to get "lost" or "ghost" sounds now but I'm still getting effects in sound volume that I don't like and haven't yet been able to resolve.

Dennis

PS:
I'm not going into detail over my changes because:
1. I'm teaching myself C# as I go along.
2. I'm still rather hazy on most aspects of Open Rails code structure because my background is longtime 3GL and Basic Assembler programming and this new-fangled Object Oriented coding is doing my head in sometimes.
3. In view of the above I don't want someone blowing up their OR setup by trying my amateur code changes.

[markus_GE]

So I´m not the only one experiencing these "ghost sounds" somewhere random along the route? (I wouldn´t have been able to read this into any above post...)

Cheers, Markus

[BB25187]

Hi,

On my side, I did not notice any "ghost" sounds so far. Only fading..

gpz, on 26 December 2013 - 08:21 AM, said:

The most helpful thing would be to set up a test case where it happens always, or at least at most of the times.

Yes, clear: this is the thing we should do. In my case, the activity which exposes the problem in a systematic way is relatively brief (about 25 minutes). It only requires a small number of trafic and loose consists (but some of them aren't straightforward to install). The real trouble is that it is run on a route which is not published yet. I will contact the authors and check if they authorize me to grant you access.
I tried to adapt this activity to a former version of the route, also removing the traffic and loose consists in order to simplify things, but then the problem does not happen anymore. So, we must handle the initial, more complex setup.

Regards

[gpz]

Couldn't it be reproduced by using a saved state? That 25 minutes of run after each small code change doesn't sound developer-friendly at all. ;)

[BB25187]

gpz, on 26 December 2013 - 01:21 PM, said:

Couldn't it be reproduced by using a saved state?

Unfortunately not. As I wrote above:

BB25187, on 26 December 2013 - 06:12 AM, said:

- When the problem appears, saving/resuming the activity restores sounds with their expected volumes.

But the good news is that saving/resuming seems to be a reliable workaround.

gpz, on 26 December 2013 - 01:21 PM, said:

That 25 minutes of run after each small code change doesn't sound developer-friendly at all. :)

I fully agree. This is another reason why isolating a test setup is not obvious! ;)