I tested FMOD Studio API on my phone but when using AAudio, the app crashed.
The audio suddenly stopped.
The timing was very random but mostly happened within 20 seconds.
Whenever the audio stopped, I got the below Logcat message.
E | AAudio | stream not closed, in state 3
- When the above happened, the app crashed within around 30 seconds.
This timing was also irregular.
Test Environment :
6/9/19 2.00.04 - Studio API minor release (build 104705)
- Android Studio 3.4.2 | Visual Studio 2019 | Windows 10 64bit Professional
- Samsung Galaxy S7 Edge (Android 8.0, 64bit, with all the latest software updates by Samsung)
- Tested both libfmod.so and libfmodL.so.
ARM and ARM64 builds using both Debug and Release mode.
Audio Source File : MP3, 44100Hz, Stereo, 16bit, 192kbps, 00:03:56, 5.42MB
Doesn’t happen with OpenSL ES output mode.
Calling FMOD_System_SetOutput(FMOD_OUTPUTTYPE_AAUDIO) or not calling FMOD_System_SetOutput() at all causes the issue.
Java and C source files have the basic minimum code.
Only FMOD_System_PlaySound() was called ONCE.
Tested using default settings.
Sample rate, buffer size… Didn’t touch anything.
There are NO DSPs.
FMOD API was used on a newly created native worker thread, but, of course, that was after being attached to JVM.
Happened while in the foreground.
Called org.fmod.FMOD.init(this) properly.
To give FMOD System enough time, I even put a 20 second delay after System.loadLibrary(“fmod”) and org.fmod.FMOD.init(this) calls.
Tried FMOD_CREATESAMPLE, FMOD_CREATESTREAM, and FMOD_CREATECOMPRESSEDSAMPLE.
Tried with other audio files but still the same.
Btw, may I ask a question?
When System.loadLibrary(“fmod”) is called on the Java side, does the FMOD System initialization happen asynchronously on the native side?
I’m asking this because, during the test above, my app crashed with a message complaining about something like “JNI_OnLoad is not called yet” and only could workaround it by inserting a sleep line.
I failed to reproduce the issue, and I might have done something stupid, but at that time, giving FMOD System enough time solved the problem.
Now, even without any sleep lines, the app works fine (if the output mode is OpenSL ES).
So I want to ask if the initialization process is asynchronous. And if yes, then is there any way for us to know if the process is done already?
I wanted to add to the original post but for some reason I can’t edit anymore…
Anyways I even tested Unity asset version of FMOD but it failed with the exact same error message. (IL2CPP, ARM64 build with Unity 2019.2.3f1)
I could only avoid the issue by adding the line ‘system.setOutput(OUTPUTTYPE.OPENSL)’.
Calling ‘system.setOutput(OUTPUTTYPE.AAUDIO)’ or not calling ‘system.setOutput()’ at all causes the app crash.
PS. Just noticed one more difference between AAudio and OpenSL ES mode in Unity.
When the Unity app goes to the background or the phone screen goes off, the audio stops working with the error message above. Also pulling down Notification bar causes the same issue. On the other hand, OpenSL ES mode version keeps working whatever I do.
PS2. I tested again my Android Studio version and it acts just like the Unity version.
When I pull down the notification bar, the audio stops.
Below is Unity C# test code :
public class Main : MonoBehaviour
const string szFile =
system.init(1024, INITFLAGS.NORMAL, System.IntPtr.Zero);
system.createSound(szFile, MODE.CREATESAMPLE, out sound);
system.playSound(sound, cg, false, out channel);
I haven’t been able to reproduce the issue here using the code you provided. Are you able to provide the entire logs from the app, preferably while using the FMOD logging libs.
You can download the APK file, Unity project source files and log files from here.
By the way, could you answer the first comment, please?
PS. Maybe this, this, this may have something to do with this issue.
System.loadLibrary(“fmod”) is called at static initialization time for Java and is synchronous. FMOD initialization occurs much later when you call into native.
Thanks for the links, this does look like something we will have to fix on our end.
Thanks for your answer and the confirmation!
PS. I confirmed the above code worked fine on an Android 8.1 device.