0
0

I have two newbie questions.

1: Where can I download documentation for the FMODex API – at least a summary of the functions and arguments?

2: I managed to get FMOD_System_PlaySound() to function in my 3D simulation/graphics/game engine, but it takes what seems like much too long to return from the function. I wonder if I have something wrong with the arguments and it is blocking in the function until the sound has completed… or something. I have tried all the following but they all take a long time to return:

[code:34nw13x1]// FMOD_MODE fmod_mode = FMOD_HARDWARE | FMOD_LOOP_OFF;
// FMOD_MODE fmod_mode = FMOD_HARDWARE | FMOD_3D | FMOD_LOOP_OFF;
// FMOD_MODE fmod_mode = FMOD_HARDWARE | FMOD_NONBLOCKING | FMOD_LOOP_OFF;
FMOD_MODE fmod_mode = FMOD_HARDWARE | FMOD_NONBLOCKING | FMOD_3D | FMOD_LOOP_OFF; // nominal
// FMOD_MODE fmod_mode = FMOD_SOFTWARE | FMOD_3D | FMOD_LOOP_OFF;[/code:34nw13x1]

This is the function call my program executes to create the sound (once, during program initialization).
[code:34nw13x1] fmod_result = FMOD_System_CreateSound (fmod_system, (char*)pathfilename, fmod_mode, 0, &fmod_sound);[/code:34nw13x1]

This is the function call my program executes each time the code plays the sound.
[code:34nw13x1] fmod_result = FMOD_System_PlaySound (fmod_system, FMOD_CHANNEL_FREE, fmod_sound, 1, &fmod_channel);[/code:34nw13x1]

The sound is not destroyed until the application completes, because the sound will be played at various times.

As a test I have the sound play at the end of my collision detection routine when it detects a collision between objects. The sound itself is just a very short click sound to indicate objects ran into each other (a collision was detected). My collision detection routine is lots of code, and takes about 60,000 cpu cycles to execute, whether it detects collisions or not when I comment out the line to play the sound. When I play the click sound upon detecting a collision, that jumps from 60,000 cpu cycles to more than 2,000,000 cpu cycles, which is about 700 microseconds. This is true whether the sound I choose lasts just an instant (like the click sound) or much longer (like 3 seconds). So the play function is not blocking until the "play" completes.

Maybe if I had API documentation I could find the problem, if my code does indeed have a problem. But something is wrong, because FMOD is in many games, and they can’t be tolerating this much overhead. I hope. I have the most recent version of FMOD_Ex installed (v4.32.08). My operating system is winxp64 and my application compiles and executes as a 32-bit mode application in VisualStudio2005pro.

  • You must to post comments
0
0

remove the non blocking flag too. and make sure your sounds are wav for sound effect.

and use the create stream method (in tut in help) for all sounds not of wav format

  • You must to post comments
0
0

The documentation is installed along with the API. If you installed it via the executable downloaded from the website, then it should put an entry in your start menu for the documentation. If (for whatever reason) that shortcut doesn’t exist, you can find the documentation at:
<path to FMOD install>\documentation\fmodex.chm

You should definitely be using software sounds, not hardware sounds. The last line in your FMOD_MODE list looks like the best one. You might also try adding FMOD_NONBLOCKING to the FMOD_SOFTWARE side. (Though, that should just control how the sound is loaded from disc, not how it’s played at runtime.)

I would also recommend that you not call FMOD functions directly from inside of your physics code. When you do FMOD_System_PlaySound(), FMOD shouldn’t doing much on the main thread (you are only calling FMOD functions from one thread, aren’t you?) other than setting up the play to start. The performance hit you’re seeing could very well be attributable to something as simple as cache misses. All of your physics state is in cache, but then you suddenly switch to calling FMOD functions, which goes and accesses a whole bunch of memory that you’re not currently using, kicking your physics state out of cache, which then has to be brought back in as soon as the sound code has finished executing.

My recommendation would be to store physics collision events in a list or something in your physics code, then, after the collision detection has finished, play a sound (or execute a callback which plays the sound) for each collision. That way the sound code isn’t interrupting your physics code.

Whether or not this cache issue is the problem you’re experiencing, reading through the documentation and examples (both of which you can find in the FMOD install directory) will be helpful.

Hope that helps!

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.