startEngine crashing on Android #1
Comments
|
Hello, any update on this? I have the exact same problem in the latest version (0.3) |
|
Hi, I didn't have any time yet to debug this, but I noticed that when it raises the Generic Error, that if I try again, it usually seems to work. |
|
Thanks for the suggestion, I'll try that. yes that's not a cool solution hehe. |
|
Dig a bit more down in this issue and I think I got the point. For what I've understand AAudio (based on system state) sometimes can be slow to start, especially in low end devices (the stress test crashes on my device extremely rare, while happens much more frequently on the emulator). It's also advised in the MiniAudio's code: So basically yes, the solution is to wait AAudio until it starts. Considering that MiniAudio runs in its own thread detaching the initialization from the rendering loop can be an idea, and instead calling |
|
Just want to mention my new workaround which consist of setting the Master Volume to 0 and back to 1 instead of stopping and starting the engine. |
|
Seeing both of these in production as well on 0.3. On create()
and on resume()
The crashes so far are on devices on Android 11 about it's early to tell if other OS versions will crash as well (didn't want to push the realese to all users) and crash rate so far is around Has anybody made any progress on this? @fgnm Can you please explain a bit more on the suggested fix/workaround? |
|
So guys, thank you so much for all the reports. Appears that AAudio is quite buggy on many Android versions, and this issue appears to be one of those bugs. MiniAudio actually support AAudio from SDK >= 26 (Android 8), Oboe (google/oboe#473) and Unity 2023.1.0 (https://unity.com/releases/editor/whats-new/2023.1.0) allow AAudio from SDK >= 27 (Android 8.1). while the In the try {
miniAudio.startEngine();
} catch (Exception e) {
e.printStackTrace();
//Manually check if current platform is Android and SDK >= MA_AAUDIO_MIN_ANDROID_SDK_VERSION
miniAudio.resetAAudio();
miniAudio.startEngine();
}It's a temporary API just for testing, I'll add a safe check to prevent crashes if invoked on other platform later, but meanwhile this appears to be a good solution which at least always recover the stress test proposed by @klianc09 |
|
It passes my stress test 👀 you have my attention. |
|
I think that with 004490c this issue can be finally considered completed.. I'll leave open until the next release anyway. |
|
Tested 0.4-SNAPSHOT on my devices and there is no crash with my stress test.
I'm happy and optimistic about this fix. |
|
I launched my app on Google play store and I am receiving crash error from some devices. I used 0.4-SNAPSHOT. The error codes are: And another crash:
Another crash: [split_config.arm64_v8a.apk!libgdx-miniaudio.so] Java_games_rednblack_miniaudio_MiniAudio_jniGroupFade |
I have in my list of TODOs to create an issue here on my experience on crashes both on iOS and Android but as a general advice try/catch (MiniAudioException) all MiniAudio startEngine/stopEngine/dispose calls. Some of the crashes seem not to be fatal and are recoverable (if you still want info about them, if you use Crashlytics you can record non fatal exceptions and add any additional custom log). My experience on Android is that AAudio is a bit buggy (not sure if it's the MiniAudio backend or AAudio itself) and most of the errors are from Android 12+ devices. I think @fgnm may have a solution to add a config option to choose OpenSL backend for all versions. UPDATE: I forgot, have a look at native crashes (you can see the in Play Console or setting up NDK Crashlytics to log them), in my case they are more common than Java Exception crashes. |
|
Thanks @obigu. |
|
I think we can consider this issue closed, the problem comes from bugs in AAudio implementation for some Android versions. If you still have issues and don't need AAudio specific features (mostly low latency) you can easily disable with |
That Are you still seeing this crash in Google Play? |
|
@znakeeye interesting the double-free catch! I really hope this could be the real culprit for this weird issue... To answer your question, I think that most of us switched to OpenSL backend (me too) to avoid buggy AAudio |
When calling stopEngine and startEngine, sometimes one of two things can happen:
Tested on:
Samsung Galaxy M21 (Android Version 10)
Huawei P7-L10 (Android Version 4.4.2)
(both devices show this behaviour)
I've created an example that reproduces the issue here: https://github.com/klianc09/miniaudio-mvce/blob/main/core/src/mvce/miniaudio/MiniAudioMVCE.java
The text was updated successfully, but these errors were encountered: