I am relatively new to FMOD and don’t [i:1dbjm08j]exactly[/i:1dbjm08j] know how to phrase my question so bear with me…
I am programming a game engine in C++ and am currently trying to get a sound system working.
My main engine is in one solution which creates a .lib file that I include into a test program in another solution.
Having the test set up so that when I click the up arrow a sound clip runs, I discovered a problem.
If I click the up arrow while the window is still loading, the sound clip runs perfectly.
However, if I wait for the engine to fully initialize then the sound comes out rather scratchy.
This scratchy version of the sound clip, I found, could not be stopped by "FMOD_Channel_Stop."
In addition, I placed a line of code ( "MessageBox( 0,0,0,0 );") before the line of code where the audio system updates (in the engine’s main loop) and even if the window is fully initialized the sound runs fine.
I hope that some "FMOD guru" as seen this before, or something like, it because that is the best that I can describe it.
If you have any idea, please let me know!
- matthewsweda asked 6 years ago
[quote:3rifk9y3]I don’t know what to do with the profiler once I create the system using: "FMOD_INIT_ENABLE_PROFILE."[/quote:3rifk9y3]
Open up FMOD Profiler while your game is running and type in the IP address of the game. If the game is running on the local machine just use the default IP (127.0.0.1). Then click ‘Connect’.
I still haven’t found anything…
How do I use the profiler tool because I haven’t found any code that seems out of place and I don’t know what to do with the profiler once I create the system using: "FMOD_INIT_ENABLE_PROFILE."
Thanks – Matt
This is what I’ve found from trying to get this to work:
If there is a message box on the screen when the sound is triggered to play, the sample sounds normal and starts playing when I close the message box. The sample sound scratchy when played, however, at any other time. The type of message box I used is the kind that demands input from the user before proceeding. Somehow this affects fmod. [b:38ig136d]There is no difference in the CPU’s performance[/b:38ig136d] between when the sound is normal and when the sound is scratchy, or metallic sounding.
That’s all I got so far and I’ll keep updating my findings here…
Hi Mathew, welcome to the FMOD forums!
That’s quite an unusual problem, I can’t think of anything specific which would cause that. There are a couple of common gotchas for new users I’ll just run through them quickly:
All FMOD functions return an FMOD_RESULT which can indicate a real error that must be handled. Some FMOD errors are fatal such as FMOD_ERR_MEMORY.
All FMOD functions must be called from one thread. (usually the main thread)
System::update must be called regularly (usually done in the graphics render loop), some internal FMOD stuff like channel clean up happens here.
It’s also worth mentioning the FMOD Profiler tool is a good way to get some extra insight into what’s going on inside FMOD. If you initialize the System with FMOD_INIT_ENABLE_PROFILE then you can connect FMOD Profiler to the game and see things such as CPU usage as well as sound levels. ‘Scratchy’ sound may indicate excessive CPU usage.
Alas, after a ton of failures to find the problem I believe that I have the answer.
The problem lay in the test project and NOT the engine.
Setting up my application like so:
"if( GetAsyncKeyState( VK_DOWN ) )
g_Engine->p_Audio->play( "explosion" );
The problem is that in the time I have my finger on the down arrow there are multiple messages sent to the audio handler to play the sound.
This results in multiple instances of the same sound being played on top of each other.
Once I changed the code so that the sound could only be played one time per call the sound ran fine!
Thanks for your help! Also I now have a new respect for the profiler! 😀
If anything else pops up I’ll let you know but for now I’ll just say: "Another problem solved thanks to the forums!" 😀
The only thing I could tell that was different is that when the scratchy sound played there are a lot more attached "blocks" (<- my novice side is showing…) than when the sound plays normal. Also, most of the "blocks" disappear when I uncheck "excessive inputs."
Does this explain anything?
Please login first to submit.