3D Audio Concepts

[proof88]

TL;DR: use 2D sounds whenever possible, because it requires the least work. For example: weapon change sound is okay to be 2D, nobody cares.

However, weapon pickup sound might be reasonably 3D, because the sound position relative to the camera gives you an extra hint about your own location in the screen in a crowded scene.

As experimented in v0.2.6, there are 2 types of 3D audio:

• position only in the moment of start playing, no need to reposition later, example: explosion;
• position and continuous reposition needed, example: player high fall yelling.

The latter requires us to save their handles for later referencing, otherwise we cannot reposition in consecutive frames. The former might also require us to save their handles, because gun shot sound instances should be played separately. Currently gun shots just played for the current player for their own shots.

Also, per-instance handles are also needed for player sounds which are hearable by other players. For example, player landing sound is hearable by everyone, we need handle so only that player's landing sound is stopped/played in the moment of landing, other players' landing sound is not affected.

All 3D sounds require min/max distance and attenuation model to be set (default model is NO attenuation).

I need to find solution for this popping issue I also experienced: https://github.com/jarikomppa/soloud/issues/175

Tasks needs to be created for the following:

• make gun shots hearable by other players too;
• make player die sound hearable by other players too.

In the future I will also need to think about optimizing network usage by making the server NOT sending out packets about player events that are too far, for which the sound's max distance can be also used, however this needs further investigation as suck packets might control other, non-audio things too.

[proof88]

Also one interesting thing to note: when a sound becomes inaudible due to being too far from the listener, it can have different behavior based on configuration:

• continue ticking (played silently), like area-specific ambient noise or music that should keep going on silently;
• be paused;
• be killed.

For gunshot fire sounds that can have many inaudible instances, maybe we should set "be killed" so that less resource is used, less instances stay "active". We dont want to hear them later, no need for ticking or be paused. I believe this way we can also win some performance. I dont remember the default value but this should be also considered later.

[proof88]

So overall, regarding the inaudible behavior I talked about in my previous comment, the default is to be paused, and not killed. For now I'm setting kill, because otherwise I heard explosion sounds as soon as I entered into their configured distance, much later than they were actually played. This is because they were paused.