ZDoom

Hey Chris, I tried the new DLL out - sounds good, from a far distance. :) The barking is drowned with reverb. This seems to be the behavior of GZDoom 4.5.0 restored. However, this also made me realize some mistakes I made in this thread:

I wrongly stated that the mix becomes dryer the closer you get to the sound source in GZDoom 4.5.0. Such a thing was never the case. Interesting that the person I am reporting this on behalf for, also mistakenly assumed the same thing.

So in conclusion:

- New DLL has reinstated GZDoom 4.5.0 behavior, as far as reverb mix goes. Thank you. :)
- Would be cool (as an additional feature) to make it so that moving closer to a sound source will gradually reduce the reverb mix. MAPINFO feature maybe?

EDIT: thinking about it, it'd probably make sense to apply that additional feature as a new SNDINFO keyword, to be defined per sound. Additionally, modder would be able to specify the lowest mix amount a reverb can have on a sound, as a percentage. For example, a modder would want to set up a specific sound such so that even if the player is standing right up to the thing and its in their face, the most dry amount that sound would go down to is 40%. Anyway, this is all separate from the actual initial issue in the OP (the new DLL seems to have fixed it) - I could have a tackle at this from the scripting glue perspective, once I know how to get the sound backend stuff to do what I want. :)

EDIT 2: Made a new thread about the custom reverb mix thing, as it's not relevant to the actual "bug" being reported in the OP

For Windows, you can try the OpenAL Soft DLL here (64-bit, built with VS2017). The zip contains soft_oal.dll which should be renamed to OpenAL32.dll and placed next to gzdoom.exe (make sure to rename/backup the OpenAL32.dll that's already there, so it can be restored as needed).

I've been adjusting OpenAL Soft's initial reverb decay to be somewhat more logical, and it seems to be helping. The demos seem to be behaving well, both the one in this thread (you can still hear echoes when the barks are distant) and the one in the aforementioned thread (the very distant sounds aren't audibly echoing where they shouldn't be). I tried the adjustments mentioned in the last post and it didn't have much noticeable affect, so if more fundamental changes are going to be needed anyway, I think it's better to go at the issue at the source (OpenAL itself). There may be more tweaks to it in the future (see the comment in the relevant commit), but this seems much closer to expected behavior.

The AppVeyor link will be valid for about a month, when it purges old build artifacts, so be sure to hold on to the dll if it works. There will be newer artifacts from newer commits, so there will still be newer dlls available regardless, but unless you're keen on going bleeding-edge, holding on to one that's known to work isn't a bad idea. There will be a new OpenAL Soft release "soon" that a future GZDoom can be packaged with too, there's just been a few recent-ish additions that have needed an unexpected amount of testing and fixes before I feel confident in a release.

There's a couple things I could try. I really don't want to revert the positioning method back to how it was, since it was ugly, unnecessarily complex, and didn't produce an initial reverb decay that could be considered "right" for custom or doom-style rolloff. What I'd do instead is, for those modes disable OpenAL's default distance attenuation (leaving the initial reverb decay alone) and don't mess around with the reference distance, and apply the distance attenuation manually to the dry path. This is probably what I should have done in the beginning since the desired gain needs to be calculated anyway, and is closer to what it was like while having more sane behavior.

Alternatively, leave the distance attenuation handling code as it is, but disable the automatic initial reverb decay for the effect slot, and calculate/apply that initial decay manually to the wet path. This still leaves the question of how exactly to calculate it, but it opens up more options.

Or third, both. Having manual control over both the dry path attenuation and wet path initial decay separately would be more flexible overall. Though only the first option is really necessary to fix this issue and there's no mechanism currently that could take advantage of the second. The second can always be added later if it becomes desirable.

Hi, sorry for being late to get back into this.

Considering the established behavior in GZDoom 4.5.0 (and also might affect already-released mods) was that the wet mix increased with distance - that behavior should be reinstated back.

Alternatively, a MAPINFO option to choose whether the wet mix is normal or inversed in relation to sound source distance.

If you're not familiar with the MAPINFO scripting glue for it, I can help out. I just need to know how to "reverse" the reverb's wet mix with GZDoom's current codebase.

Looking at the list of commits, perhaps https://github.com/coelckers/gzdoom/com ... 7d95377876 is responsible for the change between 4.5.0 and 4.6.0. Before that commit, it would move the sound source position to cause the default logarithmic rolloff to generate the appropriate dry path attenuation for Custom- and Doom-style rolloff. With that change it instead alters the reference distance, which is a simpler and more efficient method to create the same dry path attenuation, however it altered the difference between the source and listener positions (essentially, x/y is the same for the distance attenuation, but y-x is different for the initial reverb decay).

To be clear though, neither method is right, for whatever "right" means in this context. Both methods are teasing the data given to OpenAL to get a desired result on the dry path, which influence the initial reverb decay in different ways for different sounds, and is almost assuredly different from what FMOD did. There's nothing said anywhere about a sound's initial reverb decay increasing with distance, yet that's clearly supposed to happen as mods rely on it, so something is needed. And given that Doom uses exaggerated distances and non-accurate distance attenuation, I'm at a loss for what it should be like and need some guidance for the best way to proceed.

I think decay based on distance is fair, given the classic nature of the engine. Doesn't have to be too physically accurate. :)

Here's a video comparison - in GZDoom 4.5.0, the effect is wet with distance - after that GZDoom version, the effect is dry with distance - so it's behaving in the exact opposite behavior. Unfortunately I'm not able to pin down which commit exactly this happens...

(PS: I'm actually reporting this on someone else's behalf. I am going with only whatever info they provide me. I've edited the first post to clarify this)

Sounds like a consequence of fixing this issue:
viewtopic.php?t=63524

Put simply, Doom's sound distance handling is odd and not physically accurate at all. Which is causing weird interactions with a portion of OpenAL's code that is based on (somewhat informed) guesswork.

The deal is this: reverb decays over time in an environment as a result of reflecting off of and being absorbed by surfaces. As you move away from a sound, it takes longer for the direct sound to reach you, with the reverb taking even longer while it reflects off surfaces during that time before ever reaching you. So as a sound moves into the distance, the amount of reverb you hear is implicitly reduced. Reverb engines implement this as a statistically modeled initial reverb decay that's applied based on the sound distance. Of course, commercial implementations, like you'd find on hardware cards or FMOD, are proprietary (closed source "secrets", or restrictively licensed), so OpenAL Soft has to make something itself that seems close enough to what apps would expect with other implementations. The method employed works by taking the distance between the sound sound and listener, the speed of sound, and the reverb decay rate, and applies an initial decay given how much time would've passed for the direct sound to reach the listener. While this seems fairly close, there could well be differences when considering various edge and corner cases, particularly given Doom's inaccurate sound distance modeling. It's also possible a similar thing would happen with FMOD, it's just been so long since (G)ZDoom used it that it's not obvious.

There are ways of handling with this, though. An app can toggle off this automatic rolloff and calculate its own (or no) initial decay given the sound distance. It can also apply an initial reverb decay that's based on the distance attenuation of the dry sound. Given the aforementioned bug report, having no initial decay would be wrong. So if the default automatic decay is also not good, another method needs to be chosen. Either an initial decay that's based on the distance attenuation (not accurate, but maybe an acceptable compromise) or a custom calculation.

Excuse the weird thread title. Character limits, etc. :P

This is something that has been broken for quite some time now. I'm not exactly sure since when, but I would have to guess it was around the release of GZDoom 4.5.0.

Reverbing works the wrong way around. In all of the Reverbing Presets that I have tested, distant sound effects sound clear as day while nearby sound effects have a strong echo going on. I don't believe this is intended behavior in most of the presets.

In the example provided the 'Sewer Pipe (21, 0)' reverb preset is used with a pinky on the other side of the room playing a 'Woof' sound effect. After spawning, this sound effect plays clearly (in the context of a sewer pipe, this would be the case if the subject was close). As you move closer towards the pinky, the playback of the 'Woof' sound effect becomes more and more reverbed and echo-y, as if it becomes more distant.

Intended behavior would be to have this play the other way around. It should have an echo when far away, and become more clear as you move closer.

EDIT: for clarification, I am reporting this on someone else's behalf. I've quoted the text to clearly convey this.