Info Layering Sounds in OMSI 2

Road-hog123

An Orange Bus
Administrator
UKDT
Dec 10, 2015
1,784
Omsi's sound engine is quite good in many ways, but also has some strange quirks that if not understood can lead to odd or bad sounding results and frustration. One thing in particular that affects all sorts of different sound design is what happens when you take two very similar or identical sound files and play them over the top of each other.
Take for example a reversing beeper, it can be heard loudly outside the bus and through open windows or doors, but quieter and more muffled through the back wall of the bus when all direct sound paths are blocked.
Now, this can be fairly simply implemented by playing a recording of the beeper only outside the bus and a second more muffled recording inside the bus and allowing Omsi's built-in "Snd_OutsideVol" variable control how much of the exterior sound you can hear when inside the bus. However, what you would find is that when you do that you run into all sorts of difficulties with phase difference.
See, you can play the exact same sound file twice and Omsi will play those two sound files with a different phase difference each time. Fortunately they'll have the same tempo, so the sound will be consistent while it's actually playing, but if there's any sort of rhythm or beat that's supposed to line-up, it won't.
This inconsistent phase difference isn't just something that happens each time your start Omsi either, if you set your two sound files to have their volume controlled by the same variable, each time the volume isn't 0 they'll have a different phase difference.
I recorded an example of this earlier while experimenting with this, the beep sounds are the same sound file, both being turned on and off by the elec_busbar_main variable, here's the section where I configured the two sounds:
Code:
[sound]
beep_short.wav
1

[3d]
-0.6
5
1
1

[volcurve]
elec_busbar_main

[pnt]
0
0

[pnt]
1
1

[sound]
beep_short.wav
1

[3d]
-0.6
5
1
1

[volcurve]
elec_busbar_main

[pnt]
0
0

[pnt]
1
1
And here's how the phase difference changes each time I turn the electrics on:
Sometimes the two sounds have the same phase difference, other times it's not. There's no way of predicting it.
Now, I did some further investigation, taking a longer sound that noticeably repeats (a default Spandau announcement) and playing it twice, again with the volume being controlled by the same variable. The same thing was happening, each time the volume was brought up the phase difference would have changed.
Now, what this told me is that when sound volume is reduced to 0, sounds don't stop playing. If the playback was cancelled and restarted when required, both sounds would start playback very close to the beginning of the sound (the "bong" in the announcement), but they don't. The sounds also didn't pause and resume, the point they'd start up again would vary each time I turned up the volume and it wasn't where they last were. What this means is that either the sounds are paused when inaudible, but after an inconsistent amount of time or, more likely, the sounds keep playing but their low volume pushes them right to the bottom of the priority queue of sounds to process, allowing small amounts of time each frame before they're considered to build up or for more important sounds to prevent these silent sounds from playing at all.
 
Last edited:

The British Gamer

Veteran Member
Dec 29, 2016
1,140
Omsi's sound engine is quite good in many ways, but also has some strange quirks that if not understood can lead to odd or bad sounding results and frustration. One thing in particular that affects all sorts of different sound design is what happens when you take two very similar or identical sound files and play them over the top of each other.
Take for example a reversing beeper, it can be heard loudly outside the bus and through open windows or doors, but quieter and more muffled through the back wall of the bus when all direct sound paths are blocked.
Now, this can be fairly simply implemented by playing a recording of the beeper only outside the bus and a second more muffled recording inside the bus and allowing Omsi's built-in "Snd_OutsideVol" variable control how much of the exterior sound you can hear when inside the bus. However, what you would find is that when you do that you run into all sorts of difficulties with phase difference.
See, you can play the exact same sound file twice and Omsi will play those two sound files with a different phase difference each time. Fortunately they'll have the same tempo, so the sound will be consistent while it's actually playing, but if there's any sort of rhythm or beat that's supposed to line-up, it won't.
This inconsistent phase difference isn't just something that happens each time your start Omsi either, if you set your two sound files to have their volume controlled by the same variable, each time the volume isn't 0 they'll have a different phase difference.
I recorded an example of this earlier while experimenting with this, the beep sounds are the same sound file, both being turned on and off by the elec_busbar_main variable, here's the section where I configured the two sounds:
Code:
[sound]
beep_short.wav
1

[3d]
-0.6
5
1
1

[volcurve]
elec_busbar_main

[pnt]
0
0

[pnt]
1
1

[sound]
beep_short.wav
1

[3d]
-0.6
5
1
1

[volcurve]
elec_busbar_main

[pnt]
0
0

[pnt]
1
1
And here's how the phase difference changes each time I turn the electrics on:
Sometimes the two sounds have the same phase difference, other times it's not. There's no way of predicting it.
Now, I did some further investigation, taking a longer sound that noticeably repeats (a default Spandau announcement) and playing it twice, again with the volume being controlled by the same variable. The same thing was happening, each time the volume was brought up the phase difference would have changed.
Now, what this told me is that when sound volume is reduced to 0, sounds don't stop playing. If the playback was cancelled and restarted when required, both sounds would start playback very close to the beginning of the sound (the "bong" in the announcement), but they don't. The sounds also didn't pause and resume, the point they'd start up again would vary each time I turned up the volume and it wasn't where they last were. What this means is that either the sounds are paused when inaudible, but after an inconsistent amount of time or, more likely, the sounds keep playing but their low volume pushes them right to the bottom of the priority queue of sounds to process, allowing small amounts of time each frame before they're considered to build up or for more important sounds to prevent these silent sounds from playing at all.
Wow, how long did it take u to type that roadhog?