Inconsistencies in distance factor for 3D audio

Fmod doesn’t work for me in current master, as in no sound can be heard. I traced that to some variables in Fmod-related code not being initialized, so compiler did who-knows-what. When I initialized those, it started working again.

But, the variables in question also include distance factor (or speed of sound) handling, and there are some inconsistencies there. Both between Fmod and OpenAL, and also within each. It is stated that the default value for distance factor is 1.0, and that Panda3D units are by convention feet, but the internally set default is 3.28 for OpenAL (for Fmod it was uninitialized). This default was then used in OpenAL to multiply the speed of sound in feet, which is obviously wrong.

How should this be resolved? One way is to ensure that default distance factor is indeed 1.0 for units in feet, and to change OpenAL and Fmod code to internally rescale stuff properly. The other way is to document that default distance factor is in fact 3.28, and to simply remove all other internal rescaling.

I attach the patch for the second way. With this, the Doppler effect sounds the same with both OpenAL and Fmod using same distance factor.
audio_distance_factor.patch (6.5 KB)

Thanks for reporting this.

I think the factor should be in units per meter. It’s a bit silly to use a non-standard unit for this. While we’re at it we should just standardize it to that; we can make a configuration variable for restoring the old behaviour for people who rely on it and don’t feel like changing their code.

I’m extremely busy with the 1.9 release cycle, but it’d be great if this could still be in. If you could make a pull request on GitHub, that would be great.

I agree it is best to stick to units per meter. But what do you propose for the default value, 3.28 or 1.0? That is, whether Panda units are to be considered feet or meters by convention.

I think configuration variable for old behavior would be inconvenient. The current behavior is self-inconsistent, so it would mean keeping this odd code around. I think that those not willing to make a small update to their code for this, would also not be willing to switch to Panda 1.9 altogether.

Yeah, I’ll give it a shot with the GitHub request :slight_smile:

Yeah, maybe you’re right.

I don’t know of anyone who considers Panda units feet rather than meters; I’m just a bit reluctant to break backward compatibility. But maybe it’s a good change, especially if we document well how to revert to feet (eg. by changing audio-distance-factor in Config.prc).