0
0

I don’t have the return code; I just have a minidump which shows that the getDriverCaps call is not returning FMOD_OK. The minidump is from a live product with an unknown user.

Here is the startup code:

FMOD_CHECK_RESULT(FMOD::System_Create(&PSystem));

UINT version = 0;
FMOD_CHECK_RESULT(PSystem->getVersion(&version));
FUN_ASSERT(version == FMOD_VERSION);

// Manual says the following is important for Windows
FMOD_CAPS caps;
FMOD_SPEAKERMODE speakermode;
FMOD_CHECK_RESULT(PSystem->getDriverCaps(0, &caps, 0, 0, &speakermode));

The minidump also says:

caps 900 unsigned int
speakermode 4667314 FMOD_SPEAKERMODE
version 266244 unsigned int

Any idea? Bad drivers? Should I just continue on?

Tom

  • You must to post comments
0
0

Unbelievable. Received 2 minidumps today, both are the (fr_gdc == FMOD_OK) assert. The minidump includes a bunch of locals but excludes the one I am interested in – fr_gdc. Weird. I wonder what the voodoo behind the locals selection is. Will have to iterate again, but will test edge cases a bit more first.

  • You must to post comments
0
0

OK, resolved.

I managed to repro the problem by disabling my audio device. The getDriverCaps error code was FMOD_ERR_INVALID_PARAM.

Daytron’s solution seems good, thanks! It looks like Windows startup code needs to be something like this:

[code:2516hte3]
FMOD_CHECK_RESULT(FMOD::System_Create(&PSystem));
FUN_ASSERT(PSystem != NULL);

UINT version = 0;
FMOD_CHECK_RESULT(PSystem->getVersion(&version));
FUN_ASSERT(version == FMOD_VERSION);

int num_drivers = 0;
FMOD_CHECK_RESULT(PSystem->getNumDrivers(&num_drivers));
if (num_drivers == 0)
{
LOG(L"Warning: no audio drivers. Disabling audio.\n");
PSystem->setOutput(FMOD_OUTPUTTYPE_NOSOUND);
}
else
{
FMOD_CAPS caps = 0;
FMOD_SPEAKERMODE speakermode = (FMOD_SPEAKERMODE) 0;
FMOD_CHECK_RESULT(PSystem->getDriverCaps(0, &caps, 0, 0, &speakermode));
FMOD_CHECK_RESULT(PSystem->setSpeakerMode(speakermode));

if (caps & FMOD_CAPS_HARDWARE_EMULATED)
{
FMOD_CHECK_RESULT(PSystem->setDSPBufferSize(1024, 10));
}
}
[/code:2516hte3]

Followed by your init call.

Without the setOutput FMOD_OUTPUTTYPE_NOSOUND, in my case a subsequent createSound fails with FMOD_ERR_UNINITIALIZED presumably due to internal setDriver failing. The init itself succeeded.

Brett you might like to update your recommended Windows startup code to handle the no drivers case. I don’t know who these people are with no audio, but…

Developers, test the no-drivers case! :-)

The fmodex.dll!1007aaf3() exception is unresolved. I’ll post again if I get repeats.

Tom

  • You must to post comments
0
0

Can anyone help?

So far this appears to be the only crash my players are experiencing. Several have had this.

Would like to know the ramifications of the getDriverCaps failure.

In the next release I can find out the error code but am hoping to address this off the bat if anyone has some suspicions.

Thanks

  • You must to post comments
0
0

Well, unpleasantly surprised to find from user minidumps that even the above code (with num_drivers > 0) STILL sometimes fails in getDriverCaps.

According to the minidumps, caps is still 0 but speakermode has been set to -1.

I could iterate to find the error code, but that takes several weeks and leaves my customers asserting. So for now I will just test the getDriverCaps return code and react accordingly.

This combined with various short-callstack fmodex dll access violations (mentioned elsewhere) accounts for around 50% of my live game crashes.

  • You must to post comments
0
0

Could fmod comment please?

This is the only thing crashng my game.

  • You must to post comments
0
0

Never heard of this. Use the logging version to find out errors, make sure you’re not using a bad system pointer, and also you might be using an old version of fmod (you never said what version).

  • You must to post comments
0
0

System pointer must be fine; return code from System_Create is OK as implied by macro, and no null-deref on the pointer.

Version as stated is 266244 = hex 41004 = 4.10.04

It appears I should try 4.14.01.

I would never know about this issue except that my release exe has asserts on and a mechanism to fetch the minidumps. But out of several hundred downloads I have had 5 people getting a bad return code from the getDriverCaps. I don’t know what percentage consent to upload the mindump.

My options are:

  • gather more info into the minidump – the getDriverCaps return code.
  • handle the bad error code and hope it doesn’t result in run-on problems.

Cheers.

  • You must to post comments
0
0

Check some of the provided fmod examples, they use getDriverCaps.

  • You must to post comments
0
0

Do you ever call getNumDrivers to check if the machine has any audio driver installed before calling getDriverCaps? You never know.

  • You must to post comments
0
0

[quote="daytron":3ddndljk]Do you ever call getNumDrivers to check if the machine has any audio driver installed before calling getDriverCaps? You never know.[/quote:3ddndljk]

I was thinking the exact same thing as I read the original post. :)

Tom, I would recommend reading through the whole of this thread…

[url:3ddndljk]http://www.fmod.org/forum/viewtopic.php?t=9305&postdays=0&postorder=asc&start=0[/url:3ddndljk]

… as there is a lot of useful startup related stuff there that might not be covered in the docs or samples.

Hope it helps!

  • You must to post comments
0
0

Thanks guys.

It looks to me like the recommended startup code needs improving? Here again is my startup code – slightly strengthened from my OP.

[code:z3xeywce]PSystem = NULL;
FMOD_CHECK_RESULT(FMOD::System_Create(&PSystem));

UINT version = 0;
FMOD_CHECK_RESULT(PSystem->getVersion(&version));
FUN_ASSERT(version == FMOD_VERSION);

FMOD_CAPS caps = 0;
FMOD_SPEAKERMODE speakermode = (FMOD_SPEAKERMODE) 0;
FMOD_RESULT fr_gdc = PSystem->getDriverCaps(0, &caps, 0, 0, &speakermode);
FUN_ASSERT(fr_gdc == FMOD_OK);[/code:z3xeywce]

My FMOD_CHECK_RESULT macro asserts if not FMOD_OK.

[b:z3xeywce]I updated my applicated with version 4.14.01.[/b:z3xeywce]
I was expecting to receive a minidump that told me fr_gdc.

However, instead, using 4.14.01, the first minidump I received hit an access violation rather than one of my asserts:

Unhandled exception at 0x1007aaf3 in armyofearth_cr_0.517_268937971_OS5.1.2600_951696521208448404.dmp: 0xC0000005: Access violation reading location 0x017f0000.

i.e: callstack just shows:

fmodex.dll!1007aaf3()
[Frames below may be incorrect and/or missing, no symbols loaded for fmodex.dll]

so I don’t know where this happens in relation to my startup code, but guessing it is within the startup segment posted.

With respect to the posted link – if getNumDrivers returns zero, should we essentially shut down audio?

Brett, hope you can enlighten. The only reason I learned about this is because I have a mechanism to receive minidumps; presumably countless products have shipped with this same startup code (without the asserts) – but what is the knock-on?

Tom

  • You must to post comments
0
0

If getNumDrivers returns zero, you could disable audio output with something like:

pFmodSystem->setOutput(FMOD_OUTPUTTYPE_NOSOUND);

and maybe inform the user of the problem.

  • You must to post comments
Showing 12 results
Your Answer

Please first to submit.