It is a know bug for Android 4.0.0 to 4.0.3 that when defining multiple cpu architectures ( APP_ABI := armeabi armeabi-v7a ), system will load library for armeabi even if it should use armeabi-v7a (https://code.google.com/p/android/issue … l?id=25321), resulting in corrupted sounds played by fmod.
I’ve tried a couple of workarounds found on the net but none working.
Any help?
Thanks for reporting the sound corruption issue with armeabi, I’ve fixed this for our next release.
Are you saying that the armeabi version of FMOD isn’t working correctly causing the corruption?
If so is it easy to reproduce the corruption? It would be good to investigate this for anyone who requires use of the older armeabi variant.
Unluckily I don’t have an Android with the old armeabi architecture for testing, but on a 4.0.3 I can test on I get this behaviour:
according to the known bug of 4.0.0 to 4.0.3 Androids with armeabi-v7a architecture, if the apk package contains both armeabi and armeabi-v7a binaries, armeabi libraries will be loaded when calling System.loadLibrary(“fmod”) and System.loadLibrary(“fmodstudio”) instead of armeabi-v7a ones.
It’s not great that a bug exists causing armeabi to be selected when armeabi-v7a should be but I am concerned that armeabi is producing corrupted sound. It should be fine (albeit a little more expensive CPU wise).
To try and reproduce this corruption I forced armeabi on my Nexus 5 with “APP_ABI := armeabi” but the FMOD examples worked as expected (no corruption), can you confirm that the examples are corrupted when you do this?
I just launched the “simple_event” sample project built with APP_ABI := armeabi only on a 4.1.2 Android and sounds played are corrupted ( buzzing sounds ).
I ran into this when testing on a Kindle Fire HD (based on 4.2.2) with the armeabi FMOD shared library. Sounds played as noise. Once I switched to the armeabi-v7 library, everything worked as expected.