0
0

Cheers.

I’ve been prototyping things with FMOD Ex and I’ve encountered some unexplained crashes. These crashes didn’t seem to occur with single-thread version of the prototype – I first encountered then in my three thread version. To minimize the change of all this being fault of out-of-sync threads, I reduced threads to two (windows message handler thread and actual prototype thread), but that didn’t help. I scanned through the forums for similar issues, but didn’t seem to come across any, so here we go;

The first issue encountered was that occasionally (but very rarely), FMOD Ex fails to start up properly. It goes through initialization without giving an error, but not a single sound is played upon request. Also, when it comes time to shut FMOD down, it crashes on system->release().

The second issue occurs more often, but still rarely. Everything goes fine until it’s time to shut FMOD down and it crashes on system->release().

Like I said, everything went smoothly until I moved into multithreaded program structure. Like I described, I stripped away everything too fancy it’s now just Windows message handler thread and linear prototype thread (with FMOD).

So; Are there some sort of special precautions I must take with multithreaded app as opposed to basic, single thread program? Perhaps something I’ve missed while studying the documentations?

For background info, I’m currently using FMOD Ex 4.14.06, Windows Vista, sound drivers are up-to-date and the programming tool used is Visual Studio 2008 Standard Edition.

Any help is GREATLY appreciated!

Yours,

Jouni "Necrophilissimo" Lahtinen

  • You must to post comments
0
0

We’ve said many many times on this forum, and in our documentation that we dont support users calling fmod functions from multiple threads. You have to call all fmod functions from the main thread. There is no reason to move fmod calls into other threads because everything is negligible in speed or if it isnt, as a nonblocking feature (ie FMOD_NONBLOCKING) that puts certain code in its own safe, criticalsection protected threads.

  • You must to post comments
0
0

If you really really have to, and be sure about that, you can make it work as long as you protect all access to FMOD functions with your own mutex. If you don’t know what this means, don’t do it.

One case where it might make sense is on loading screens. You might want to cross fade music, and I don’t think it is currently possible to schedule such a fade, so you must set the volume each frame. And this could be done from a different thread. But this requires you to protect all access to FMOD functions.

To sum it up, I can see cases where you would want to use multiple threads, but Brett is right. Avoid it if you can. Design your engine in such a way that you can load data / levels / whatever whilst still getting some kind of framerate for FMOD.

  • You must to post comments
0
0

Perhaps I wasn’t clear enough with my description (sorry for that) but all FMOD functions are in one thread. Actually, in my prototype, the other thread is only for taking care of obligatory Windows messages.

  • You must to post comments
0
0

If all FMOD calls are in one thread, I don’t know of any reason why it shouldn’t work. My guess, some function is called from another thread anyway… You could try asserting that the thread id doing the calls never changes.

  • You must to post comments
0
0

I’ll try that. Thanks 😀

  • You must to post comments
0
0

[quote="necrophilissimo":1k6izwn4]I’ll try that. Thanks :D[/quote:1k6izwn4]

So, you have FMOD in the main thread and you want to show a message box without the sounds stalling on you? That without having to move system::update in the main application message loop maybe?

here’s how I did it.
[code:1k6izwn4]
export double FMODUpdate(void)
{
if(!inited) {{FMODASSERT(FMOD_ERR_INITIALIZATION);}}
FMODASSERT(FMOD_System_Update(mainsystem));
return (double) 1;
}

HANDLE updatethread = 0;
int threadstate = 0;
DWORD WINAPI UpdateFunction( LPVOID lpParam )
{
while(threadstate == 1)
{
Sleep(16);
if(inited)
FMODUpdate();
}
threadstate = 2;
ExitThread(0);
}
export double FMODUpdateTakeOverWhileLocked()
{
if(!inited) {{FMODASSERT(FMOD_ERR_INITIALIZATION);}}
if(updatethread) {FMODASSERT(FMOD_ERR_INITIALIZED);}
DWORD dontcare = 0;
threadstate = 1;
updatethread = CreateThread(
NULL, // default security attributes
0, // use default stack size
UpdateFunction, // thread function name
0, // argument to thread function
0, // use default creation flags
&dontcare); // returns the thread identifier
return (double) 1;
}

export double FMODUpdateTakeOverDone()
{
if(!inited) {{FMODASSERT(FMOD_ERR_INITIALIZATION);}}
if(!updatethread) {FMODASSERT(FMOD_ERR_INITIALIZED);}
threadstate = 0;
while(threadstate != 2) Sleep(4);
CloseHandle(updatethread);
updatethread = 0;
threadstate = 0;

return (double) 1;

}
[/code:1k6izwn4]

So basically, I call

FMODTakeOverWhileLocked();
Dialog->ShowModal();
FMODTakeOverDone();

  • You must to post comments
Showing 6 results
Your Answer

Please first to submit.