ZDoom with OpenAL

[Graf Zahl]

I'm not really sure but I think that it is intended. At least the old code recalculated the sound curve's contents the same way.

[Chris]

Comparing to the original Hexen with DOSBox, it seems the rolloff is more drastic in ZDoom.

The pow makes sense for ROLLOFF_Doom, which has the note "Linear rolloff with a logarithmic volume scale". Though applying the pow to ROLLOFF_Custom seems a bit odd because you'd think the pow() would be pre-calculated for the table and thus avoid the unnecessary (and costly, for 386/486 days) real-time calculation.

[Graf Zahl]

Can it be that the original sound system had logarithmic parameters somewhere? I really don't know and I also don't have the time to check right now. Since you seem to be working on sound anyway, could you compare whether Hexen needs linear or logarithmic scale? It shouldn't be too hard to test, should it?

[Nash]

Hi, sorry to interrupt all the technical talk, but does this thread mean we'll be getting a fully-GPL-compatible (G)ZDoom sooner than we thought?

That would be great news. :D

[Chris]

Hexen uses ROLLOFF_Custom. If I change S_GetRolloff to return the soundcurve value after division, distant sounds become a bit louder. Looking at its SNDCURVE lump, it does appear as though it's logarithmic.. or at least not linear. I traced the loaded S_SoundCurve array, counting the number of times a value appears in sequence, starting from index 0:

Code: Select all

127 - count: 1
125 - count: 1
124 - count: 1
123 - count: 1
122 - count: 1
121 - count: 2
120 - count: 2
119 - count: 2
118 - count: 2
117 - count: 3
116 - count: 3
115 - count: 3
114 - count: 3
113 - count: 4
112 - count: 4
111 - count: 4
110 - count: 4
109 - count: 5
108 - count: 5
107 - count: 5
106 - count: 5
105 - count: 6
104 - count: 6
103 - count: 6
102 - count: 6
101 - count: 7
100 - count: 7
...

[randi]

The sound code has to convert the volume scale. Doom/Heretic/Hexen calculate a volume level and then multiply the sample data by that amount. (I assume; can't check to be sure without DMX's source, but it seems like a reasonable assumption.) This gives a volume scale that is perceptually lorgarithmic, and a volume level of 0.5 is drastically quieter than a volume level of 1.0. FMOD Ex, on the other hand, uses a volume scale that is perceptually linear, so a volume level of 0.5 sounds half as load as 1.0.

(Sorry, I do not know the technical names for these.)

[Graf Zahl]

Hi, sorry to interrupt all the technical talk, but does this thread mean we'll be getting a fully-GPL-compatible (G)ZDoom sooner than we thought?

That would be great news.

We'll see. Unfortunately I can't help right now. I am extremely busy with an ultra-urgent work project until the end of this week so I won't be able to do any checks with it before Saturday.

[Chris]

The sound code has to convert the volume scale. Doom/Heretic/Hexen calculate a volume level and then multiply the sample data by that amount. (I assume; can't check to be sure without DMX's source, but it seems like a reasonable assumption.) This gives a volume scale that is perceptually lorgarithmic, and a volume level of 0.5 is drastically quieter than a volume level of 1.0. FMOD Ex, on the other hand, uses a volume scale that is perceptually linear, so a volume level of 0.5 sounds half as load as 1.0.

This doesn't sound right. If the sample data is merely multiplied with the volume, it will be linear (0.5 is half volume, 0.25 is 1/4th, etc). It's entirely possible Doom's rolloff isn't linear (eg. halfway between min and max distance is much lower than half volume), though just multiplying the sample data with a 0..1 value is linear. Hexen for sure doesn't have a linear rolloff, even if the sndcurve is applied linearly.

But as far as I can tell, the sndcurve lump is meant to be applied linearly (scaled by 127 or some such, of course). It doesn't really make sense otherwise, and not doing so seems to produce a rolloff that drops off much quicker than the original game.

[randi]

This doesn't sound right. If the sample data is merely multiplied with the volume, it will be linear (0.5 is half volume, 0.25 is 1/4th, etc).

I'm talking about the way your ears perceive loudness. FMOD Ex is atypical in that all the volumes you pass to it are perceptually linear; FMOD 3's are perceptually logarithmic, like probably most audio libraries, and I quickly discovered the difference while implementing the rolloff callback and comparing it against 2.2.0.

SNDCURVE is just a substitute for the division done by Doom. Doom divide's the sounds distance by the maximum audible distance and passes that as the volume parameter to DMX. Heretic/Hexen lookup the distance in SNDCURVE and pass that as the DMX volume parameter. In either case, that parameter is perceptually logarithmic (a linear gain) and needs to be converted to a scale that is perceptually linear for use with FMOD Ex. Perhaps I don't have the conversion quite right, but it sounded fine to me.

I imagine this discussion is complicated by the way a linear volume sounds logarithmic, but a logarithmic volume sounds linear.

[Chris]

SNDCURVE is just a substitute for the division done by Doom. Doom divide's the sounds distance by the maximum audible distance and passes that as the volume parameter to DMX. Heretic/Hexen lookup the distance in SNDCURVE and pass that as the DMX volume parameter. In either case, that parameter is perceptually logarithmic (a linear gain) and needs to be converted to a scale that is perceptually linear for use with FMOD Ex. Perhaps I don't have the conversion quite right, but it sounded fine to me.

I imagine this discussion is complicated by the way a linear volume sounds logarithmic, but a logarithmic volume sounds linear.

Ah.. so then that pow() should only be applied to the volume being passed to FMOD, and not to OpenAL (which does simply multiply the volume with the sample data)? That would make sense (and means S_GetRolloff needs to be modified to move the powf() into fmodsound.cpp).

[Graf Zahl]

I'd rather pass it as a parameter to S_GetRolloff. I'll change S_GetRolloff as soon as I find the time.

[Chris]

Hmm, the updated code isn't making sense to me.

Code: Select all

        if (logarithmic)
        {
                if (rolloff->RolloffType == ROLLOFF_Linear)
                {
                        return volume;
                }
                else
                {
                        return float((pow(10.f, volume) - 1.) / 9.);
                }
        }
        else
        {
                if (rolloff->RolloffType == ROLLOFF_Linear)
                {
                        return float(log10(9. * volume + 1.));
                }
                else
                {
                        return volume;
                }
        }

If the rolloff is a linear type without a logorithmic adjustment, shouldn't the volume, which was just calculated with a linear rolloff, be passed back as-is? And if the rolloff is linear with a logarithmic adjustment, it would still need to be adjusted for FMOD Ex's tinkering? OpenAL has a linear rolloff type, which calculates it the same way (eg. volume = 0.5 when the distance is halfway between min and max) and applies it directly. As far as I understand it, since FMOD Ex uses a perceptually linear scale, it'll always need to apply the adjustment to the result, regardless of the rolloff type (log, custom, doom, linear), to get the expected result, whereas other systems that use a mathmatically linear scale would never need to.

I ask because there's a couple extensions being proposed for OpenAL which would let me use its distance attenuation functionality, without having to "post process" and manually adjust gains. So for sounds that use linear, I can set the linear rolloff type, for sounds that use log, and I can the I3DL2 (hardware-style) logarithmic rolloff type, etc.

EDIT: I'm also getting the error:
s_sound.cpp error: ‘pow_x87_inline’ was not declared in this scope
which is kind of odd since the define for pow is right after the extern inline version of the function. But the old code used powf instead of pow.

[Graf Zahl]

If the volume has to be tinkered for FMOD due to a logarithmic scale, obviously, what's a linear scale for FMOD now becomes logarithmic for other libraries. The calculation in there is just the inverse function of what's done for the other case in FMOD.


Regarding the error, just re-add powf. It looks like some compiler-side bug.

I ask because there's a couple extensions being proposed for OpenAL which would let me use its distance attenuation functionality, without having to "post process" and manually adjust gains. So for sounds that use linear, I can set the linear rolloff type, for sounds that use log, and I can the I3DL2 (hardware-style) logarithmic rolloff type, etc.

You will never be able to use these extensions unless they are allowing the calculation of the rolloff on the application's side. ZDoom allows non-standard curves and I seriously doubt that any extension mechanism will be able to handle them. As you see, even FMODs default features weren't good enough.

[Chris]

If the volume has to be tinkered for FMOD due to a logarithmic scale, obviously, what's a linear scale for FMOD now becomes logarithmic for other libraries. The calculation in there is just the inverse function of what's done for the other case in FMOD.

True. But the more I give it some thought, it just seems there's something wrong with the function. ROLLOFF_Log implements I3DL2-compatible attenuation, but doesn't need to be modified before sending to FMOD. If FMOD is going to modify the volume to be on a perceptive volume scale, shouldn't it need to be modified just like ROLLOFF_Custom? And if you have ROLLOFF_Linear implement a linear rolloff scale, shouldn't it also need to be modified before sending to FMOD?

You will never be able to use these extensions unless they are allowing the calculation of the rolloff on the application's side. ZDoom allows non-standard curves and I seriously doubt that any extension mechanism will be able to handle them. As you see, even FMODs default features weren't good enough.

They do. The one extension allows for an application to specify one or many custom rolloff curves (basically exactly like S_SoundCurve, except its not limitted to just one and it's using floats as the attenuation values instead of 7-bit integers; it would also allow blending between entries, so it wouldn't jump from value to value.. it could have a more gradual change). The other extension allows each source to specify its own distance model, instead of it being global for the context. So one source can use linear, another can use log/i3dl2, another can use sndcurve, etc.

[Graf Zahl]

If the volume has to be tinkered for FMOD due to a logarithmic scale, obviously, what's a linear scale for FMOD now becomes logarithmic for other libraries. The calculation in there is just the inverse function of what's done for the other case in FMOD.

True. But the more I give it some thought, it just seems there's something wrong with the function. ROLLOFF_Log implements I3DL2-compatible attenuation, but doesn't need to be modified before sending to FMOD. If FMOD is going to modify the volume to be on a perceptive volume scale, shouldn't it need to be modified just like ROLLOFF_Custom? And if you have ROLLOFF_Linear implement a linear rolloff scale, shouldn't it also need to be modified before sending to FMOD?

I'm sorry but I can't help you with this. My unterstanding of the technical issues is basically non-existent.