I would like to know too.
We believe we have found the issue: due to Unity using the rdynamic flag which causes symbol resolution to start with the application binary, meaning our integration libs end up linking to the (very) old version of FMOD that Unity uses internally.
The only way to fix this is by changing the flags we use to build our libs.
This is yet to pass through QA but we are expecting it to go out in the next patch release at the beginning of April.
I saw that you had launched a new version (2.01.00) today.
Does this version have a fix for this issue?
Unfortunately not, that version was already in QA before we got the fix in, it will be available in the next patch version (2.00.09 & 2.01.01) which should be out in the next week.
Any update on when the fix will be released?
Been 3 weeks and 2.01.00 is still the latest version it looks like.
(2.00.09 & 2.01.01 do not appear to exist)
I would like to know too.
Apologies, the release got pushed back to the beginning of May.
Thank you for your patience.
What’s the status of this?
I saw that has launched the new versions: (2.01.01) and (2.00.09).
Does these versions have a fix for this issue?
Can confirm that version 2.01.01 fixes the issue for us. (Did not test with 2.00.09)
Yes, the latest release does contain the fix for this.
@cameron-fmod Can you confirm what the earliest version of FMOD is that has the fix?
2.00.09 ? or is it 2.01.01?
At present the latest “Unity Verified” version is 2.00.09 - does the fix exist in that version?
Or do I need to download an early access version?
Also - does the version of FMOD stuido Suite need to match the version of the Unity Package? or can I use FMOD Suite 2.00.10 with a different Unity Package version
The fix is in 2.00.09, you can see our detailed revision history in our docs:
You can generally use the same major version (eg. 2.00.xx) between the API and Studio.
Hello,This issue happens when I ran on Android device. The apk was built successfully with Unity 2019.2.21f1 and FMOD Integration 2.01.04. And the log shows:
SystemNotInitializedException: [FMOD] Initialization failed : FMOD.Studio.System.create : ERR_HEADER_MISMATCH : There is a version mismatch between the FMOD header and either the FMOD Studio library or the FMOD Low Level library.
at FMODUnity.RuntimeManager.CheckInitResult (FMOD.RESULT result, System.String cause) ()
at GameManager.RegisterDataManager ()
I just built my game using Unity 2019.3.8f1 and 2019.3.0f6, and I finally solved it with Unity 2019.3.0f6
I have the same problem now if i build with FMOD 2.01.05. (Unity : 2020.1.7f1)
I reverted back to FMOD 2.00.12. and the Build works now.
Which is a bummer, cause i made a lot of work that now i cannot open in earlier FMOD.
So i guess FMOD does not support beta Unity builds?
Which is the latest supported FMOD for Unity?
The version of Unity should have an effect on this, are you using the docs guide for Updating the plugin? It looks like something is not being updated to the new version correctly.
I know this is an old issue, but is it possible we’ve got a regression on this bug with version 2.02 (early access at the time of writing) for Linux?
When I use the libfmod.so.12 libraries, all works fine. Replacing them with the newer libfmod.so.13 libraries results in a HEADER_MISMATCH when initializing a system object.
The same happens for the Core and the Studio libraries, both on x86_64 and arm architectures. I’m calling the C libraries using
pyfmodex (GitHub - tyrylu/pyfmodex: Python bindings for fmod ex sound library.)
We fixed this by shipping monolithic libs for Unity, which combines fmod and fmodstudio libs, due to a collision with the built in Unity audio (a much older version of FMOD).