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.
- psugar asked 12 years ago
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.
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 )
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
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
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]
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.
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.
- psugar answered 12 years ago
Please login first to submit.