Boy I’m just editing this post constantly today =)
Anyway, I found that if I just use FMOD_System_Init(), it doesn’t autodetect my output type correctly for some reason. I assume that the autodetect is trying to use DSOUND, but for some reason (unknown to me) Fmod Ex errors at this. (Although FMOD 3 appears to work with DSOUND np).
I have found that WINMM works fine, and I’m going to see if DSOUND works directly (ex: set manually using setOutput) and see what happens.
My question is, how come the autodetect isn’t picking the “working” one assuming my DSOUND output type doesn’t work…
I assume autodetect should pick the outputtype best for my enviroment, and if the first selected one doesn’t work, it moves onto another choice.
EDIT: When using setOutput, I cannot use AUTODETECT or DSOUND without it failing. I assume the AUTODETECT is selecting DSOUND due to my OS enviroment. However, for reasons unknown to me, DSOUND doesn’t work…so I am currently forcing WINMM while I do my testing.
So here is the “bug”. The autodetect is choosing DSOUND as my “best choice” but DSOUND fails…shouldn’t the autodetect then automatically go to WINMM next (and/or other ones) or do I have to manually check each output device myself?
Also, is there a reason why Fmod Ex fails for DSOUND, but Fmod 3 doesn’t fail?
My OS: WinXP Home SP1
- Shaltif asked 12 years ago
I don’t mean to bump this topic, but it’s been a weeks time, and I’ve been unable to resolve this problem. Is there anyway a new lib, header, dll, etc be made with logging so I (we) can figure out what this problem might be?
Even if it’s unfixable, I would at least like to know what could be causing the problem
I’m using the minGW compiler, and would require the .a type library (as stated above). I’m using Fmodex.dll and the .h header (not the .hpp one).
Thanks brett for taking your time to help figure this out (considering it seems I’m the only one having this issue).
I checked out 4.00.29 Beta and unfortunitly, not much has changed for this issue. I am still getting this error:
When I use DSOUND or AUTODETECT (again, autodetect is probably selecting direct sound) it errors with the DRIVERCALL error. So I still have to force WINMM to do anything. I’ll keep messing with it and maybe I can pull something off, but so far, everything I’ve tried comes up failing (with DSOUND that is). Again, other applications and FMOD 3 work with DSOUND without flaw.
If you wish to do the logging thing as suggested previous, then I will need the .a (or minGW compiler) library, along with the new logging DLL/header.
Update: Checked with the 2nd version of 4.00.30 and still getting the same results. Testing on multiple computers seems to result in same behavior.
However, I am currently investigating that it might not fully be FMOD’s fault. I am currently in the mid of doing some tests to see if I can pin-point if the cause is FMOD, or somewhere else.
I do have a question tho, what exactly would be the reasons for the above error to occur? I mean, I’ve used DSOUND before with many applications without this issue occuring. Just seems odd that just suddently, this happens.
I’ll edit back with results…
EDIT: The problem is on my end, and I’m sorry to have wasted your time. You see, I’m using a 3rd party program (ie, I’m using Game Maker http://www.gamemaker.nl ) and am using my own DLL so I can use Fmod via Game Maker (since GM is unable to directly work with your DLL due to the data type returns and sends). Unfortunitly, it appears that GM does something with DSOUND (since it does have a primative audio system of it’s own) which makes Fmod unable to use it. Why this wasn’t a problem with Fmod 3 and is now still kinda baffles me…so I’m guess I’m just stuck with WINMM for now.
Again, sorry to have wasted your time.
BTW: If you want to check out a very good media player made using Fmod 3.74 as it’s core, check out the SXMS Player.
http://shaltif.shawn64.com/ (completed applications tab)
I’m basically making a FMOD system object, then intializing…this causes the output to fail with the following message:
Then what I did was make a system object, forced a setOuput with autodetect, then initalized. Still got the same problem. I then tried DSOUND, same thing.
If I set the output type to WINMM tho, everything works fine. So I can’t imagine it being my code since I’m just making a system object then initalizing. Is there anything special I should try before initalizing with DSOUND?
DSOUND, for some reason, is failing under Fmod Ex, however all other applications, FMOD 3 and even the DirectX dxdiag says everything is running properly. This makes me conclude that something with Fmod Ex isn’t initializing correctly with DSOUND output type.
HP Pavilon a220n
WinXP Home SP1
~2.1 Ghz Processor (AMD Athlon 2600+)
128 MB nVidia GeForce FX 5200
768MB RAM – 120GB HD
Realtek AC97 Audio
Here is a simplified down version of the code that I’m using:
^That errors, unless I force output to be WINMM. I’ve also tried a force output with DSOUND and AUTODETECT, both of those fail.
So the bugs:
AUTODETECT is picking DSOUND even tho it errors…and for some reason DSOUND isn’t working, so I assume the AUTODETECT is working, but something isn’t being initialized right on the DSOUND.
EDIT: Note that this is using Fmod Ex 4.00.28 Beta and normally I have all types of if () checks to make sure all is going well, but I removed them to simplify the code example. Also, I did the test code above in a C console window and still got the same error results. So, as you can see, there isn’t much room for me to have made an error on my part unless I’m missing something I should be setting.
OK, I sent you a log from virtual PC.
Afterwards I did some digging around, and realized that the version of the DLL you sent is giving a different error code than 28 does:
C:\Documents and Settings\VPC\Desktop\examples\generatetone>generatetone
FMOD error! (44) FMOD_HARDWARE was specified but the sound card does not have the resources nescessary to play it.
Is there any way to deal with this? I’m not specifying FMOD_HARDWARE in my engine but it still fails under VPC.
I would have tried it, but unfortunitly I’m not using the Visual Studio library. I’m using Dev-C++ (or the MinGW compiler) so I would need that appropriate library before I can do testing.
(Sorry, I should have specified that).
I tried it with the supplied library, but that didn’t end up working…so, hopefully Janus’s report is helpful, or a modified .a library is required for my testing.
Also, Janus’s error does appear different then the one I have been getting (at least, when he tired the new modified Fmodex).
[quote="Shaltif":2lfl8hhc]Also, Janus’s error does appear different then the one I have been getting (at least, when he tired the new modified Fmodex).
~Brandon[/quote:2lfl8hhc]I’m not sure when it was changed, but the last time I tried it (around beta 23 or 24) I was getting errors 32 and 43, not this new one. I believe 43 is the error you’re getting, if memory serves.
I replaced the Fmod Ex and the include file (figured you shipped that for a reason). I tried with the old link file (the original .a file), but when I tried to run it, it gave me a linker error to the DLL. Or more correctly, this error. (this was on run time, not compiling, compiling worked fine)
What’s more interesting is that I’m not even using that function (figures) so I just assumed it was a linker issue. I’ll keep working at it.
Please login first to submit.