I’m trying to use FMod in a Delphi application. Currently though I have a problem; whenever I try to Init FMod using DSOUND as the output method, it crashes; BSOD, followed by lots of KERNEL32 app faults. WinMM output works fine.
If I turn down the hardware acceleration level in audio properties then it works OK. Yes, I’m using a Live! Before you say “Haven’t you read the FAQ”, I have … the weird thing is everything works fine if I use one of the FMOD samples written in C! Anything compiled in Delphi causes the crash (if I use DSOUND). I’m using latest drivers for everything too….
Is this the “normal” Live! bug? It’s really confusing me that C apps work OK but Delphi ones don’t, it’s the same DLL whatever’s calling it…
I meant that Visual C++ masks FP exceptions in its startup code where Borland leaves it alone. It is masked in the initialization of some units such as some of the OpenGL units that are available. I have never used Borland’s OpenGL units, but use the headers from sites such as [url:1s9eb0oc]http://www.delphi3d.net[/url:1s9eb0oc].
I’m wondering what would happen if multiple units set the FPU CW in their initialization units. They usually reset the CW to its previous state in the finalization section. Is the order of initialization and finalization the same, reversed, unknown?
<font size=-1>[ This Message was edited by: Sly on 2001-08-22 17:08 ]</font>
Finalization clauses execute in the exact opposite order the initialization clauses do. So the first Finalization to run is the one association with the last Initialization that executed.
Actually, I use the Delphi3d headers too, but I added the FP Mask in myself.
Borlands headers don’t restore the control word, but there is actually code in the help file for Set8087CW showing how to back up the current CW and restore it when you exit.
It must be something that Visual C++ sets when an application starts, similar to Visual C++ masking floating point exceptions by default whereas Borland does not. It only seems to happen on some systems as well. I have a SB Live Value! in my system at home and it has never crashed on me, which makes it very difficult to test for this bug. I know Brett had some newer unreleased Live drivers that apparently fixed some problems. Maybe they will fix this problem? Does anyone know if they are released yet? The latest drivers available on the Creative site are dated 11 July 2000.
I’m not sure whether you intended to mention it as a possible fix, but masking out FP exceptions seemed to fix it! Freaky.
Actually Borland’s headers do mask out FP exceptions by default …. in OpenGL apps. If I’d actually tried to use FMOD in my OpenGL app from the start it’d’ve been OK, but I just tried a basic Windows app, so Delphi didn’t set up the FP mask for me…
Maybe you should add the FP mask code to the Initialization in the FMOD Delphi header? I don’t think it can hurt anything and it certainly cured all the crashes on my system. (Tried the same app with and without the FP mask; so it’s definitely that).
Please login first to submit.