Units in FMOD's world

[Doug McCorkle]

Hey Chris,

I am digging into the issue related to the airplane example and I am guessing that we have a units problem. In the 3d example FMOD defines a distance scale factor which gets multiplied into every value that has to do with a length. In osgAudio we set a scale value of 1 which means meters but then we hand off values for velocity and position that are in feet. I think this is causing us big problems. Here is sample code from the 3d example:

/*
Set the distance units. (meters/feet etc).
*/
result = system->set3DSettings(1.0, DISTANCEFACTOR, 1.0f);
ERRCHECK(result);

/*
Load some sounds
*/
result = system->createSound("../media/drumloop.wav", FMOD_3D, 0, &sound1);
ERRCHECK(result);
result = sound1->set3DMinMaxDistance(10.f * DISTANCEFACTOR, 5000.0f * DISTANCEFACTOR);
ERRCHECK(result);
result = sound1->setMode(FMOD_LOOP_NORMAL);
ERRCHECK(result);

result = system->createSound("../media/jaguar.wav", FMOD_3D, 0, &sound2);
ERRCHECK(result);
result = sound2->set3DMinMaxDistance(50.f * DISTANCEFACTOR, 5000.0f * DISTANCEFACTOR);
ERRCHECK(result);
result = sound2->setMode(FMOD_LOOP_NORMAL);
ERRCHECK(result);

result = system->createSound("../media/swish.wav", FMOD_SOFTWARE | FMOD_2D, 0, &sound3);
ERRCHECK(result);

/*
Play sounds at certain positions
*/
{
FMOD_VECTOR pos = { -10.0f * DISTANCEFACTOR, 0.0f, 0.0f };
FMOD_VECTOR vel = { 0.0f, 0.0f, 0.0f };

result = system->playSound(FMOD_CHANNEL_FREE, sound1, true, &channel1);
ERRCHECK(result);
result = channel1->set3DAttributes(&pos, &vel);
ERRCHECK(result);
result = channel1->setPaused(false);
ERRCHECK(result);
}

Any time a distance is given the scale factor is used. I think we need to incorporate something similar into the osgAudio code base. I am guessing that the reason FMOD is sensitive to the doppler effect is because our velocities and length units are off by a factor of 3. Do you know what the default units are in OpenAL space?

Doug

[Chris 'Xenon' Hanson]

On 3/15/2011 3:50 PM, Doug McCorkle wrote:
> Hey Chris,

> In osgAudio we set a scale value of 1 which means meters but then we hand off values for velocity and position that are in feet.

Is it that veSuite uses feet, or the osgAudio examples use feet? I thought that, while
osg is generally unitless, something had led me to believe the osgAudio examples were
implicitly in meters. But this is memory from a year ago.

> Any time a distance is given the scale factor is used. I think we need to incorporate something similar into the osgAudio code base. I am guessing that the reason FMOD is sensitive to the doppler effect is because our velocities and length units are off by a factor of 3. Do you know what the default units are in OpenAL space?

I thought I provided an osgAudio API for setting the units scaling factor. I can look
later and see how openAL treats it, but I'd guess it to be more likely to be meters than
feet. Technical people seem to abhor feet, especially outside the US.

> Doug

--
Chris 'Xenon' Hanson, omo sanza lettere. Xe...@AlphaPixel.com http://www.alphapixel.com/
Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting.
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen

[Doug McCorkle]

On Mar 15, 2011, at 4:57 PM, Chris 'Xenon' Hanson wrote:

> On 3/15/2011 3:50 PM, Doug McCorkle wrote:
>> Hey Chris,
>> In osgAudio we set a scale value of 1 which means meters but then we hand off values for velocity and position that are in feet.
>
> Is it that veSuite uses feet,

We use feet in VE-Suite.

> or the osgAudio examples use feet?

I believe osgAudio as well.

> I thought that, while
> osg is generally unitless, something had led me to believe the osgAudio examples were
> implicitly in meters. But this is memory from a year ago.

I guess this would depend on the size of the geometry. I am not sure what its scale is.

>
>> Any time a distance is given the scale factor is used. I think we need to incorporate something similar into the osgAudio code base. I am guessing that the reason FMOD is sensitive to the doppler effect is because our velocities and length units are off by a factor of 3. Do you know what the default units are in OpenAL space?
>
> I thought I provided an osgAudio API for setting the units scaling factor.

I do not see anything and there is no scale factor that is multiplied into the listener's position or velocity values.

> I can look
> later and see how openAL treats it, but I'd guess it to be more likely to be meters than
> feet. Technical people seem to abhor feet, especially outside the US.

Well, in the 3D example I can play with all of the values that we set in osgAudio and all of the doppler effects and rolloffs make sense both in terms of value and in terms of audio output.

I have attached my modified 3d example that lets you move the listener forward and backward. With this example it is easy to tell the difference between the linear and log rolloff and the 3D min/max settings. Everything seems correct to me with the resulting audio but maybe I missing something. The one thing I do know is that it is near impossible to get the same result out of an osgAudio example.

Doug

[Doug McCorkle]

I forgot the attachment....

Doug

[Chris 'Xenon' Hanson]

I've stopped on my other project, and will look at this issue in an hour after I get
some dinner.

[Doug McCorkle]

Here is some useful info:

Space and Distance
OpenAL does not define the units of measurement for distances. The application is free to use meters, inches, or parsecs. OpenAL provides means for simulating the natural attenuation of sound according to distance, and to exaggerate or reduce this effect. However, the resulting effects do not depend on the distance unit used by the application to express source and listener coordinates. OpenAL calculations are scale invariant. The specification assumes Euclidean calculation of distances, and mandates that if two sources are sorted with respect to the Euclidean metric, the distance calculation used by the implementation has to preserve that order.

http://hackage.haskell.org/packages/archive/OpenAL/1.3.1.1/doc/html/Sound-OpenAL-AL.html

Doug

[Paul Martz]

If OpenAL is unitless, then I assume it must support a variable speedOfSound
setting.

How is this handled in FMOD?
-Paul

[Paul Martz]

On 3/16/2011 3:14 PM, Paul Martz wrote:
> If OpenAL is unitless, then I assume it must support a variable speedOfSound
> setting.

AL_SPEED_OF_SOUND

[Chris 'Xenon' Hanson]

Yes. And osgAudio implements this for OpenAL.