Migrating from OpenAL

Hey, I have a project/game engine that currently relies on OpenAL for audio, and I was wondering what the process for transitioning to FMOD would look like.

Has anyone done this kind of thing before? If so, what’d they suggest I do?

I also use MingW to compile my project. Does this add any more complications besides not being able to use the C++ ABI?
(Heck, what’s the difference between the C++ ABI and the C ABI anyway?)

I am not familiar with OpenAL so I am not entirely equipped to suggest the details of a transition to FMOD. Skimming the docs there are certainly high level similarities in terms of creating listeners, creating instances of source/sounds, loading audio data into them from disc, setting their positions in 3D space and finally releasing them. So on the surface it seems to me that FMOD has an obvious analog for each OpenAL API call. One potential gotcha is the need to call System::update() as well as sleep to playback audio in FMOD; I see in OpenAL you play out a source like this:

while (source_state == AL_PLAYING) {
	alGetSourcei(source, AL_SOURCE_STATE, &source_state);
	TEST_ERROR("source state get");
}

While in FMOD you update the system object and sleep for a duration:

while(true)
{
	result = system->update();
	ERRCHECK(result);
	sleep(50)
}

In terms of software design, I guess a good place to start would be to extract a common interface from your exsting audio functionality and reimplement it using FMOD. The Bridge Pattern would be a good approach to allow a graduated transition while supporting both audio systems.

I am not sure what you mean about MinGW not being able to use the C++ ABI. MinGW can compile C++ code on Windows without issue, and this includes anything using the FMOD C++ API.
There are many differences between a C and C++ ABI on a given platform- I think this might be a little out of scope for the forums, but here is an interesting presentation on ABIs and how the C and C++ ABIs tend to differ:
Jonathan Wakely- What is an ABI and Why is it So Complicated

Thanks for the response! I’ll look into using the bridge pattern.

I’ve seen people on the forums here saying that due to the way different compilers mangle C++ function names you can’t use the FMOD C++ ABI with MinGW. I tested it out myself, and ran into a bunch of undefined reference to <function name> errors in linking, unfortunately.

I see what you mean now, you are correct only the C ABI is supported for MinGW- apologies for the oversight there.

There is one other thing to look out for on Windows- you should call CoInitializeEx(nullptr, COINIT_APARTMENTTHREADED) before making any FMOD calls, and call CoUninitialize() during cleanup. More details on this, and a few other potential gotchas on Windows can be found in the Windows Platform Details section of the API docs.

Alright, thank you!