Our middleware does not automatically simulate any delay due to speed-of-sound, as such delay is almost always undesirable. There are multiple reasons for this.
Humans typically do not notice delays due to speed-of-sound, as most events that we pay attention to occur at distances and speeds small enough for the delay to be negligible. We therefore only notice delays when they are extreme, such as when standing in an echo valley, or when a very loud event occurs at a very great distance. In our experience, when players encounter delay outside of those few specific situations where they expect to hear it, they recognise it as unnatural, buggy behavior, rather than as accurate simulation. To put it another way, realistic delay sounds unrealistic more often than not.
In any game where player reaction speed is important, speed-of-sound-based delay results in audio cues that arrive a variable amount of time after the game event they herald, or in cues that arrive a significant amount of time after the corresponding event has occurred. Players often cannot usefully react to these cues, resulting in frustration.
Finally, calculating delay and buffering output for each event would consume a very large amount of system resources, and very few games allocate enough resources to audio to make accurate simulation of delay worthwhile.
Given all of the above, almost all developers prefer not to simulate delay. Instead, they ignore it except for the few situations where it would be expected, and then build it into the specific sound events that need it.
If your game project does definitely require simulation of delay for events, please contact email@example.com and let us know what specific requirements you have; We will be happy to suggest potential solutions.