Just to confirm, are you using the Unity Integration, Unreal Integration or the FMOD C/C++ API?
This crash should be fixed in the Unity Integration in the next release, in the meantime there is small change you can make to RuntimeManager.cs to workaround the issue.
Please let me know if you are not using the FMOD Unity Integration and I will investigate further.
We are using FMOD C/C++ API.
The solution in the case of the Unity integration is essentially to call java.lang.System.loadLibrary("fmod") before calling into the FMOD API. In the C++ API examples we call this from a static initialization block as described in the Android Platform Specifics section of the docs. Are you making a similar call in your application?
Weâve added all needed code as described in documentation but still having same crashes with
Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged. Do you have any ideas?
Thank you for giving that a shot. You mentioned already trying all the workarounds here, but can you please confirm whether you have also tried setting the FMOD_OUTPUTTYPE to OpenSL?
We use OpenSL only for 26 Android SDK because of the bug with AAudio in that version. Do you recomend to switch to OpenSL for all versions or what we should do?
It is probably best not to change output type for everything, but I would like to know whether any of your users who are on Android SDK 26, and therefore are using OpenSL, are also getting this Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged crash.
If you have any other device information on affected users we may be able to attempt a reproduction on our end?
We have such crashes only on Xiaomi devices with Android 11, 12. Most affected devices are Redmi Note 10/10s.
Weâve found stable way to reproduce the problem. Device is Xiaomi Note 10 pro. Before start you need to enable device option here: Options â Sound and vibration â Sound helper â Application sound control (It makes you able to control sound volume for all applications separetely). With that option enabled app crashes all the time when it goes foreground after being in background. Also itâs possibly connected with high workload of the device.
Thank you for the additional info, I have passed this onto the Development team to look into in more detail. I will see if it is possible for us to order one of these devices in; it is sometimes difficult for us to get the exact models required in our country. Can you please go into your settings, click on âAbout phoneâ and tell me what the specific Model value of your test device is?
Xiaomi Readmi Note 10 Pro 8/128
Model M2101K6G
Android Version 12 SKQ1.210908.001
MIUI Version 13.0.3.0(SKFRUXM)
Thank you for the additional device details, I have passed these details along to the Dev team.
One of our developers pointed out that FMOD 2.02.06 should not be able to produce the callstack you are seeing- just to confirm there arenât any issues with mismatched libs or anything like that can you please try re-downloading the 2.02.06 version of the FMOD API, replace your projectâs libs and includes, and see if you still get a crash on your test device?
Now the most common crashes look like this:
libaudioclient.so 0x49a98244 + 606788
libaudioclient.so 0x49a98238 + 606776
libaaudio_internal.so 0x94b59b74 + 183156
libaaudio_internal.so 0x94b4aa10 + 121360
libaudioclient.so 0x49ab9ab0 + 744112
libaudioclient.so 0x49a47a08 + 277000
libbinder.so 0x33393880 + 301184
libbinder.so 0x3339d910 + 342288
libbinder.so 0x3339d42c + 341036
libbinder.so 0x3339dcdc + 343260
libbinder.so 0x333ca418 + 525336
libutils.so 0x49be058c + 79244
libandroid_runtime.so 0x31ef34b8 + 783544
libutils.so 0x49bdfde8 + 77288
libc.so 0x313cbd44 + 986436
libc.so 0x3136857c + 578940
And in the same time nearby threads contain this:
* libc.so 0x313b6fa8 + 901032
* libc.so 0x31370c08 + 613384
* libbinder.so 0x3339d0b4 + 340148
* libbinder.so 0x3339e2f0 + 344816
* libbinder.so 0x3339e034 + 344116
* libbinder.so 0x33395b28 + 310056 * ---
* libfmod.so Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged
* libfmod.so Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged
* libfmod.so FMOD::SystemI::setInternalCallback(int, FMOD_RESULT (*)(FMOD_SYSTEM*, unsigned int, void*, void*, void*), void*)
* libfmod.so FMOD::System::init(int, unsigned int, void*)
* libfmodstudio.so0xd88fb934 + 383284
* libfmodstudio.soFMOD::Studio::System::initialize(int, unsigned int, unsigned int, void*)
or this:
libc.so 0x39486020 + 540704
libfmod.so JNI_OnLoad
libfmod.so Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged
libfmod.so Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged
libfmod.so FMOD::Geometry::getUserData(void**)
libfmod.so FMOD5_Reverb3D_GetUserData
libfmod.so FMOD5_Reverb3D_GetUserData
libfmod.so FMOD::SystemI::createDiskFile(char const*, FMOD_CREATESOUNDEXINFO*, FMOD::File**, bool*)
libfmod.so FMOD::System::update()
libfmodstudio.so 0x95558d14 + 314644
libfmodstudio.so 0x95560f88 + 348040
libfmodstudio.so FMOD::Studio::CommandReplay::setUserData(void*)
libfmodstudio.so FMOD::Studio::CommandReplay::setUserData(void*)
libfmodstudio.so FMOD::Studio::CommandReplay::setUserData(void*)
libfmodstudio.so FMOD::Studio::CommandReplay::setUserData(void*)
libc.so 0x39485588 + 537992
libc.so 0x394261dc + 147932
I am not sure on the reliability of those fmod callstacks there, but this one has some promising details:
The order of the libs being called resemble that of a known issue on Android, which should be resolved in Android 13. Here is the stack trace of that bug for comparison:
libaudioclient.so (android::AudioTrack::setVolume(float, float)+468)
libaaudio_internal.so (aaudio::AudioStreamTrack::doSetVolume()+116)
libaaudio_internal.so (aaudio::AudioStream::MyPlayerBase::playerSetVolume()+340)
libaudioclient.so (android::PlayerBase::setVolume(float)+148)
libaudioclient.so (android::media::BnPlayer::onTransact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+668)
libbinder.so (android::BBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+252)
libbinder.so (android::IPCThreadState::executeCommand(int)+1048)
libbinder.so (android::IPCThreadState::getAndExecuteCommand()+164)
libbinder.so (android::IPCThreadState::joinThreadPool(bool)+72)
libbinder.so (android::PoolThread::threadLoop()+28)
libutils.so (android::thread::_threadLoop(void*)+264)
libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+148)
libutils.so (thread_data_t::trampoline(thread_data_t const*)+408)
libc.so (__pthread_start(void*)+264)
libc.so (__start_thread+68)
If you were to make a debug/logging build of your application I suspect you would see it ending on android::AudioTrack::setVolume as well. Since you have a test device available, perhaps you could try updating to Android 13 and see if you can still reproduce this crash?
Yes, it seems that problem caused by that Android bug. As I understood it can be fixed by using OpenSL for Android versions less than 33(Android 13). But here you said that itâs not best idea. Can you explain why?
Previously we had seen that Unity users had not benefited from switching to OpenSL:
At the time I thought it would have been a useful data point to see if switching to OpenSL would change things when using just the FMOD C++ API and not Unity, but when you mentioned you were using OpenSL for Android 26 that opened up new questions and I thought testing with OpenSL for all API levels wouldnât have been necessary.
However, your case seems to have a different root cause to the Unity crashes, and since you now have a test device and reliable reproduction steps I think it would be useful to see if switching to OpenSL makes a difference.
Hello,
I am bumping this thread because we still have this issue on Android and cannot update to the new FMOD versions until it is. Here is stack trace of what is happening in prod on latest FMOD
Fatal Exception: java.lang.UnsatisfiedLinkError: No implementation found for void org.fmod.FMOD.OutputAAudioHeadphonesChanged() (tried Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged and Java_org_fmod_FMOD_OutputAAudioHeadphonesChanged__)
at org.fmod.FMOD.OutputAAudioHeadphonesChanged(FMOD.java)
at org.fmod.FMOD.access$000()
at org.fmod.FMOD$PluginBroadcastReceiver.onReceive()
at android.app.LoadedApk$ReceiverDispatcher$Args.lambda$getRunnable$0$android-app-LoadedApk$ReceiverDispatcher$Args(LoadedApk.java:1790)
at android.app.LoadedApk$ReceiverDispatcher$Args$$ExternalSyntheticLambda0.run(:2)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7872)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
Are you using Unity, Unreal, or the FMOD Engine C/C++ API?
Hello Jeff,
Sorry for the delay. We are using the core C/C++ API. This bug is causing us many problems, because we require the latest Android NDK, which doesnât seem to work with older versions of FMOD. If you require more information, please let me know.
What version of FMOD are you using?
Just to clarify, is the problem that you need to use an old version of FMOD and you are hitting this error with the latest Android NDK? Or is the problem that you are trying to update to a new version of FMOD, but are hitting this error with the new version of FMOD and the latest Android NDK?