Avoid initializing AudioEngine instance when audio is absent in AudioEvent

[andeart]

Issue:
There is a frequent (but inconsistent) crash on Android devices with Android 10 (aka API 29) and below, caused when miniaudio disposes of its AudioEngine and attempts to free its audio buffers. This specific crash is really a race condition issue with miniaudio on Android 10-, but Rive indirectly triggers this through StateMachineController.dispose(). This results in a full crash, i.e. app quits completely and unexpectedly.

More context on how this crash is triggered from Rive code...

When an AudioEvent is received in StateMachineController.applyEvents(), an instance of Rive's AudioEngine is created through the audioPlayer getter, which consequently also initializes a miniaudio player. Note that this getter is currently invoked and the AudioEngine is instantiated even if the AudioEvent lacks an audio asset.

While this is harmless on its own, in such cases where the AudioEngine is created, calling StateMachineController.dispose() later also attempts to dispose the miniaudio player, resulting in the Android crash referenced above.

The crash stack trace looks something like this...

E/libc++abi: Pure virtual function called!
F/libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 24289 (AudioTrack), pid 24246 (ter_audio_crash)
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
backtrace:
#00  pc 0x00000000000705ac  /apex/com.android.runtime/lib64/bionic/libc.so (abort+160)
#01  pc 0x00000000000500fc  /system/lib64/libc++.so (abort_message+232)
#02  pc 0x0000000000065bf4  /system/lib64/libc++.so (__cxa_pure_virtual+16)
#03  pc 0x00000000000257ec  /system/lib64/libaaudio.so (aaudio::AudioStreamLegacy::processCallbackCommon(int, void*)+1112)
#04  pc 0x000000000006c3a8  /system/lib64/libaudioclient.so (android::AudioTrack::processAudioBuffer()+2628)
#05  pc 0x000000000006b65c  /system/lib64/libaudioclient.so (android::AudioTrack::AudioTrackThread::threadLoop()+264)
#06  pc 0x00000000000136c4  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+316)
#07  pc 0x00000000000e5e4c  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+140)
#08  pc 0x00000000000cf700  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
#09  pc 0x00000000000720e8  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

On a related note, this condition also affects SoLoud, another Flutter package using miniaudio. SoLoud addresses it by switching to OpenSL for Android 10 and below.

---

Solution:
The perfect solution would be to fix the deref race conditions in miniaudio for Android 10.

But as a preventative measure in Rive, we can also avoid the crash circumstances for Rive users who don't use audio, by bypassing the miniaudio engine creation/disposal (through StateMachineController.audioPlayer) when audio is absent from an AudioEvent.

This change also provides a minor performance benefit by avoiding allocations through AudioEngine.init() if the file happens to send an empty AudioEvent.

---

Additional context:
I ran the package tests in my local clone, but they fail. As I understand, this is to be expected for now because of the custom dylib depdendencies. I tried to use the library generation script from this thread but unfortunately couldn't fix the tests. I'm happy to try any alternative suggestions to help with checks.

Let me know if I missed anything please. Thanks for creating this useful runtime!

[HayesGordon]

Hi @andeart, Thanks for the contribution. I co-authored this PR with you because we use a private mono repository and push the updates downstream to this repo.

Closing this PR, Your commit is already included and we published 0.13.16 with the fix.

[andeart]

Thanks for the assist with this, @HayesGordon !