0
0

While porting some old openAL code to FMOD for a client, I noticed that openAL appeared to have a configurable speed-of-sound parameter, but I didn’t spot any such setting. Did I miss anything, or is it just not an important parameter?

There are several other less-well-known settings I’m having difficulty mapping directly from openAL to FMOD, mostly due to my unfamiliarity with openAL, and the fact that their API and docs sort of seem rather decrepit these days.

  • You must to post comments
0
0

[quote="XenonofArcticus":2evxo1bp]OpenAL implies units are meaningless, as long as everything is in the same units (falloff distances, source/listener coordinates, etc). Can someone from Firelight comment on what the units really do affect? [/quote:2evxo1bp]
FMOD doesn’t impose any unit of measurement. However the speed of sound is a fixed constant and must be in proportion to the rest of the world. The distance factor parameter is our mechanism for adjusting the speed of sound constant to match your world scale.

[quote="XenonofArcticus":2evxo1bp]Because we’re a high-detail 3D scenegraph, we can’t always guarantee an exact framerate, so our update rate is at whatever the redraw rate is. But I don’t see any indication in the docs that this is a problem. And in my test program we’re VSYNC locked and we’re running at about 60fps, so update rate shouldn’t be the issue. [/quote:2evxo1bp]
There is no requirement that system update be called at even intervals. We calculate the time delta internally for things that need it.

[quote="icuurd12b42":2evxo1bp]//the number of times/second System::Update is called
export double FMODSetDopplerFPS(double fps)
… [/quote:2evxo1bp]
This is not needed at all, you only set these properties once at init time. To update 3d channels, you only need to set the position in world units and velocity in world units per second. Some confusion arises with people trying to use the position delta as the velocity, that will not work: it must be units/second not units/frame.

  • You must to post comments
0
0

You would have to arbitrarely set to sound (channel) to a position, then set the velocity towards an arbitrary listener… at speed

set listener to 0,0,0
set sound pos to 0,0, 100 at velocity (speed)

float speed = 3; //pass as argument, original values used
float factor = .5; //adjustment factor
FMOD_VECTOR p = {0,0,100};
FMOD_VECTOR v = {0,0,(speed * factor)}; //>0 move away, <0 move towards

channel->set3DAttributes(
&pos,
&vel
);

read set3DSettings for how to apply a world scale to your movement. but I gather, the default setting should work, as you would only have to factor the speed parameter so the effect matched the original system

  • You must to post comments
0
0

Actually the distance factor setting in System::set3DSettings is only used for doppler calculation in the fashion SPEED_OF_SOUND * distancefactor. We have SPEED_OF_SOUND hardcoded to 340, so you can use the distance factor to map our speed of sound to the speed of sound you require.

  • You must to post comments
0
0

Thanks, that exactly what I needed to know. I’ll probably have a couple other questions about mapping of value ranges between OpenAL’s model and FMOD’s model. Will post later.

BTW, unrelated: What does FMOD (or did FMOD originally) stand for anyway? I can construe that maybe it was "Firelight MOD player" library?

  • You must to post comments
0
0

[quote="mathew":10dyvkq9]Actually the distance factor setting in System::set3DSettings is only used for doppler calculation in the fashion SPEED_OF_SOUND * distancefactor.[/quote:10dyvkq9]

Matthew, let me double-check, I think you mean "dopplerscale" and not "distancefactor" in System::set3DSettings(). From the help file:

[quote:10dyvkq9]The doppler scale is a general scaling factor for how much the pitch varies due to doppler shifting in 3D sound. Doppler is the pitch bending effect when a sound comes towards the listener or moves away from it, much like the effect you hear when a train goes past you with its horn sounding. With "dopplerscale" you can exaggerate or diminish the effect. FMOD’s effective speed of sound at a doppler factor of 1.0 is 340 m/s.

The distance factor is the FMOD 3D engine relative distance factor, compared to 1.0 meters. Another way to put it is that it equates to "how many units per meter does your engine have". For example, if you are using feet then "scale" would equal 3.28. [/quote:10dyvkq9]

So, if I understand correctly,

dopplerscale = speed / 340.0

  • You must to post comments
0
0

Another property I’m having trouble identifying an FMOD analogue to is OpenAL’s Source AL_MIN_GAIN/AL_MAX_GAIN [0.0f, 1.0f].

From OpenAL’s documentation:

[quote:2j4vv60s]AL_MIN_GAIN is a scalar amplitude threshold. It indicates the minimal AL_GAIN that is always guaranteed for this source. At the end of the processing of various attenuation factors such as distance based attenuation and source AL_GAIN, the effective gain calculated is compared to this value. If the effective gain is lower than AL_MIN_GAIN, AL_MIN_GAIN is applied. This happens before the listener gain is applied. If a zero AL_MIN_GAIN is set, then the effective gain will not be corrected.

AL_MAX_GAIN defines a scalar amplitude threshold. It indicates the maximal AL_GAIN permitted for this source. At the end of the processing of various attenuation factors such as distance based attenuation and source AL_GAIN, the effective gain calculated is compared to this value. If the effective gain is higher than AL_MAX_GAIN, AL_MAX_GAIN is applied. This happens before the listener AL_GAIN is applied. If the listener gain times AL_MAX_GAIN still exceeds the maximum gain the implementation can handle, the implementation is free to clamp. If a zero AL_MAX_GAIN is set, then the source is effectively muted. The implementation is free to optimize for this situation, but no optimization is required or recommended as setting GAIN to zero is the proper way to mute a source.[/quote:2j4vv60s]

It seems like in FMOD the Source would map to either a Sound, or more likely a Channel for a playing Sound. I don’t see any direct equivalent to Min/Max Gain. Is there such a thing, or should I just leave it unimplemented?

  • You must to post comments
0
0

Just to be clear, the calculation for pitch with respect to doppler is as follows:

pitch = SPEED_OF_SOUND * distanceFactor;
pitch -= relative_velocity * dopplerScale;
pitch /= SPEED_OF_SOUND * distanceFactor;

Where relative_velocity is the relative velocity between a sound source and the listener.

I can’t think of a direct mapping for the min/max gain values, you should probably leave that one unimplemented.

  • You must to post comments
0
0

[quote="mathew":39g3pttg]I can’t think of a direct mapping for the min/max gain values, you should probably leave that one unimplemented.[/quote:39g3pttg]

Thanks, matthew. It’s not a critical capability, but I didn’t want to omit it if there was an equivalent.

  • You must to post comments
0
0

I think I have matched the various settings as well as possible. FMOD’s Min distance seems equivalent to OpenAL’s Reference distance as best as I can tell.

However, I’m still seeing a significant difference with distance attenuation between FMOD and OpenAL. I’m wondering if anyone else has ever had to map equivalency between OpenAL and FMOD and if you have any advice.

I also see MUCH more pronounced Doppler effects in FMOD compared to OpenAL, to the point of pops, clicks and distortion if my Listener is moving about quickly. I am using nominal Doppler scale and 1.0 unit scale (meters). I can’t think of anything else that would apply. I’m avoiding using any fancy reverb, or custom falloff, it’s just regular logfalloff.

Any suggestions for where to look?

  • You must to post comments
0
0

Maybe you need FMOD_3D_LINEARROLLOFF for CreateSound

Make sure you set the listener and channel positions before you call system update. if not done in the proper order, you will get weird distortions.

Also if your world scale is off. 1 unit = 1 meter… The implementation depends on you frames per second… or how many times you call SystemUpdate per second. I use FPS, in the game engine this is for the update is called every screen refres and that is not dynamic.

You can also make sure SystemUpdate is called 30 times a second, even if your display frame rate is faster, such as in variable Frame rate games… Anyway, the game engine mine is for, the f/s is not dynamic, so I pass that value..

here is my implementaien, never mind the channel point bing passed as a double, due to the game system I interface with

[code:1js8te0f]
static float worldscale = 1;
static float deltatime = 0;

//the number of times/second System::Update is called
export double FMODSetDopplerFPS(double fps)
{
if(!inited) {{FMODASSERT(FMOD_ERR_INITIALIZATION);}}
deltatime = 0;
if(fps==0) return (double) 1;
deltatime = (float)1/(float)fps * (float)1000;
deltatime = (float)1000/(float)deltatime;
return (double) 1;
}
//eg (1/32) : 1 meter = 32 units
export double FMODSetWorldScale(double scale)
{

//FMODASSERT(FMOD_System_Set3DSettings(mainsystem, 1,scale,1));
worldscale = (float)scale;
return (double) 1;

}

//in my system, instance is a channel
export double FMODInstanceSet3dPosition(double channel,double x,double y,double z)
{
if(!inited) {{FMODASSERT(FMOD_ERR_INITIALIZATION);}}
if(!(channel>0)){{FMODASSERT(FMOD_ERR_INVALID_HANDLE);}}
FMOD_VECTOR pos = {0,0,0};

FMOD_VECTOR vel = {  0.0f, 0.0f, 0.0f };
if(deltatime)
{
    FMODASSERT(FMOD_Channel_Get3DAttributes((FMOD_CHANNEL*)(DWORD)channel,&amp;pos,0));
    vel.x = ((float)x-pos.x)*worldscale * deltatime;
    vel.y = ((float)y-pos.y)*worldscale * deltatime;
    vel.z = ((float)z-pos.z)*worldscale * deltatime;
}
pos.x = (float)x;//* worldscale;
pos.y = (float)y;//* worldscale;
pos.z = (float)z;//* worldscale;
FMODASSERT(FMOD_Channel_Set3DAttributes((FMOD_CHANNEL*)(DWORD)channel,&amp;pos,&amp;vel));

return (double) 1;

}

export double FMODListenerSet3dPositionEx(double number, double x, double y, double z, double fx, double fy, double fz, double ux, double uy, double uz)
{
if(number <1 || number > 4) {{FMODASSERT(FMOD_ERR_INVALID_PARAM);}}
FMOD_VECTOR pos = {0,0,0};

FMOD_VECTOR forward = {(float)fx, (float)fy, (float)fz};
FMOD_VECTOR up = {(float)ux, (float)uy, (float)uz};
FMOD_VECTOR vel = {  0.0f, 0.0f, 0.0f };
if(deltatime)
{
    FMODASSERT(FMOD_System_Get3DListenerAttributes(mainsystem,(int)number-1,&amp;pos,0,0,0));
    vel.x = ((float)x-pos.x)*worldscale * deltatime;
    vel.y = ((float)y-pos.y)*worldscale * deltatime;
    vel.z = ((float)z-pos.z)*worldscale * deltatime;
}
pos.x = (float)x;//* worldscale;
pos.y = (float)y;//* worldscale;
pos.z = (float)z;//* worldscale;

FMODASSERT(FMOD_System_Set3DListenerAttributes(mainsystem, (int)number-1,&amp;pos,&amp;vel,&amp;forward,&amp;up));
return (double) 1;

}
[/code:1js8te0f]

  • You must to post comments
0
0

Speed of sound is not settable in FMOD, however if your intention is to change how doppler is applied you can use System::set3DSettings to change the scale of the doppler effect.

  • You must to post comments
0
0

[quote="icuurd12b42":2ynor65s]Maybe you need FMOD_3D_LINEARROLLOFF for CreateSound
[/quote:2ynor65s]

Well, OpenAL’s rolloff model is logarithmic (IASIG I3DL2), same as FMOD, so I don’t think linear is appropriate.

[quote="icuurd12b42":2ynor65s]Also if your world scale is off. 1 unit = 1 meter… [/quote:2ynor65s]

Our framework works in meters too, so it shouldn’t be an issue. OpenAL implies units are meaningless, as long as everything is in the same units (falloff distances, source/listener coordinates, etc). Can someone from Firelight comment on what the units really do affect?

[quote="icuurd12b42":2ynor65s]The implementation depends on you frames per second… or how many times you call SystemUpdate per second. I use FPS, in the game engine this is for the update is called every screen refres and that is not dynamic.[/quote:2ynor65s]

Because we’re a high-detail 3D scenegraph, we can’t always guarantee an exact framerate, so our update rate is at whatever the redraw rate is. But I don’t see any indication in the docs that this is a problem. And in my test program we’re VSYNC locked and we’re running at about 60fps, so update rate shouldn’t be the issue.

[/quote]

  • You must to post comments
0
0

Well, the existing code takes a speed parameter, and invokes alDopplerVelocity(speed), so yes, it appears to be involving Doppler interaction, but to be honest, i don’t know the relationship between OpenAL’s speed and FMOD’s Doppler scale. Can you comment on how one would translate between the two, or is there no obvious mapping?

  • You must to post comments
Showing 13 results
Your Answer

Please first to submit.