FMOD ChannelHandle returns null in Release, but not Debug

Debug:
fmod error working 1


Release:
fmod error null 1

Greetings.

I’ve been making use of my own AudioEngine in c++, visualstudio for a group game project, and have ran into a strange issue regarding PlaySound.

As the images above show, creating a channel inside of my own “Play 3D Sound” Function has thus far been working flawlessly in Debug mode, the sound plays in the correct position, etc etc.

However as soon as we started switching to Release, the function now suddenly returns NULL on the channel handle, rather than…whatever 0xcccccccc is. Normally I create a temporary channel, define it with playsound and then set its position in the world to play properly, but in Release, it returning null results in it never being set Post play-sound, and results in a crash.

I have no clue what caused the change between the two modes, if its some internal FMOD setting I have to set at system::init, or if its completely separate from FMOD entirely, somehow.

I’d appreciate any and all answers and hypothesis regarding this.

What version of FMOD are you using, and are the examples running fine in Release and Debug mode?
I think some logging might give a better idea of what’s going wrong. You can set this up by swapping out your libs for the “fmodL” logging libs, and calling FMOD::Debug_Initialize(FMOD_DEBUG_LEVEL_LOG) at the start of your application. This should give you some more useful ingormation in your console about any internal failures. Other than that, is playSound returning FMOD_OK?

Thanks for the response!

Regarding the version, I believe I’m using FMOD Core 2.0, atleast that’s the version name mentioned in the main fmod.h file.

image

I’ve yet to try your suggested Debug method, but I am curious what Release exactly constitutes. I’ve simply initialized things as normal, following one of the guides featured on the website for fmod core. Is that the same as Release?

Playsound returns FMOD_OK correctly in visual studio’s debug.

However in its Release mode, since aTempChannel becomes null and remains as null, it returns an error-handle.

Here’s an image of my entire function, which uses Playsound.
There’s some things related to position and such which can be ignored, the main issue is tied to FMOD::Channel* aTempChannel, and the playSound call below it.

You can get the version by checking the hex value of the FMOD_VERSION preprocessor directive, it should be something like 0x00020203 for FMOD 2.02.03.

That result indicates that one of your parameters was invalid, most likely there’s a bad value in that array. So things to check would be:

  • What values are in the myNEWSounds array
  • What is the value of aSound
  • Is the value of aSound less than the length of the array
  • What is the value of myNEWSounds at index aSound.

Ah! Thank you. According to the value I saw, I appear to be using the same version as the one you gave as an example. FMOD 2.02.03.

Since my last post, I’ve realized that not only does this playsound not work, but everything just seems to have broken completely in Release mode. My entire NEWSounds array, and all of its assigned sounds are NULL.
image
Despite things still working flawlessly in Debug.
image
The values themselves are correct though. aSound’s assigned value is 19, which is the sound I called for. And the size of NewSounds is 23, which is also correct to the amount of sounds loaded. The value of aSound also doesnt exceed the length of the array or anything like that.

At this point my worry is that something in the way things are handled on startup have somehow depending on if its in Debug or Release, but from my digging around, nothing regarding my audioengine or anything else tied to it seems to have any restrictions depending on mode, or something like that.

That narrows it down a bit more and explains the crash. How/where are you populating this array of sounds?

I managed to solve it! And of course the issue was way simpler than I had thought.

In my LoadSounds function, there was indeed a “ifdef debug” line present, I had just assumed that it wasn’t affecting anything, since it never caused a crash there.

In hindsight I can’t believe I actually missed it, it’s right there in plain sight.

Regardless, thank you for the assistance, Jeff. You helped me narrow down what exactly the cause was, since originally I thought the issue was happening way deeper into the code than it actually was.

Ahh that would be an easy one to miss actually. Glad you got to the bottom of it!