0
0

Hi all,

We have a persistent crash in fmod.dll that we have been unable to reproduce reliably. It seems to happen only after several hours of gameplay . I know that FMOD 3.75 is extremely stable, so I’m guessing the fault is with our code. Having said that, does anybody have any suggestions (throw em out please!) as to what could potentially cause crashes?

The platform is Win32 using C++/OGG. We are using both streaming and resident sounds, as well as stereo/3d positional sound.

We are testing every possible parameter we can think of (including the position and velocity of 3D sounds).

Any help appreciated.
Paul

  • You must to post comments
0
0

Buggy files can cause some problems problems when using Visual Basic, but that shouldn’t occur on other languages.
You should log at certain program points to check where the problem occures, and check parameters etc.

  • You must to post comments
0
0

Is it possible you are calling fmod from timers or other threads instead of always calling it from the one thread.

  • You must to post comments
0
0

No, there is only a single game thread that makes FMOD calls; of course there are also two threads that I presume are spawned by FMOD itself, the FSOUND_Software_ThreadCallback, and the FSOUND_Stream_UpdateThread.

Further info:

It seems to crash when this call is made in the main thread, although the crash appears to be in the FMOD mixer thread:

[code:hbxzzy9a]FSOUND_PlaySoundEx( FSOUND_FREE, pSample, NULL, TRUE )
[/code:hbxzzy9a]

The call stack with the debug FMOD dll looks like this:

[code:hbxzzy9a]fmod.dll!FSOUND_Channel_Alloc(int channel=3942544, FSOUND_CHANNELBLOCK * block=0x03842014, FSOUND_SAMPLE * sptr=0x4a630ae0, int priority=-858993460, int exclude=-858993460, char stopstreamable=’Ì’) Line 502 + 0xb bytes

fmod.dll!FSOUND_PlaySoundInternal(int * channelarray=0x0012fa10, int numchannels=1, FSOUND_SAMPLE * sptr=0x4a630ae0, FSOUND_DSPUNIT * dspunit=0x003c2890, char startpaused=”) Line 784 + 0x17 bytes

fmod.dll!FSOUND_PlaySoundEx(int channel=-1, FSOUND_SAMPLE * sptr=0x4a630ae0, FSOUND_DSPUNIT * dspunit=0x00000000, char startpaused=”) Line 938 + 0x19 bytes
[/code:hbxzzy9a]

and the FMOD mixer thread is in

[code:hbxzzy9a]fmod.dll!_FSOUND_Mixer_MMXIP6() + 0x771 bytes

fmod.dll!FSOUND_Software_MixSFX(void * originalbuffer=0x003c8020, void * newbuffer=0x003c8020, int length=1024, void * userdata=0x003c2890) Line 148 + 0x16 bytes
[/code:hbxzzy9a]

The mixer thread is always in the same function when it crashes and the main thread is always in Channel_Alloc at about the same location. The lines that have given the access violation are:

[code:hbxzzy9a]mov ecx, [esi+esi]
movd mm1,dword ptr [esi*4]
[/code:hbxzzy9a]

But that doesn’t mean much.
The sample that its crashing while trying to mix is the same one that has just been played by the main thread.

More details:

I have narrowed it down such that only 3D sounds are being played. The crash stops occuring if we don’t release the samples (call FSOUND_Sample_Free) but I can’t see any way that we could be releasing prematurely. Is it possible there is a loophole in the FMOD check to make sure the sound isn’t currently being mixed before releasing or in the check to make sure it’s loaded before mixing? Or in the IsPlaying function (that’s what we use to determine when to unload)?

Appreciate any help, thanks.
Paul

  • You must to post comments
0
0

please write to support@fmod.org we may have a solution for you.

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.