Native crash in android::AudioTrack::setVolume on Android

[b_kosmowski]

Hello,

We have a long-standing native SIGSEGV crash in our Android app (.NET MAUI / Xamarin, BASS.NET 2.4.17.7 + Bass.Net.Android.Native 2.4.17, audiobook player). Stack is fully in system libraries — no BASS or our frames are unwound. Identical stack signature is reported by FMOD, Wwise and Google Oboe users, and FMOD officially classifies it as an Android framework issue. We'd like your perspective on whether anything on the BASS side could contribute and whether there's a recommended Android setup that mitigates this.

Stack:

Code Select Expand

  libaudioclient   android::AudioTrack::setVolume
  libaaudio        aaudio::AudioStreamTrack::doSetVolume
  libaaudio        <unknown>
  libaudioclient   android::PlayerBase::setVolume
  libaudioclient   android::media::BnPlayer::onTransact
  libbinder        android::BBinder::transact
  libbinder        android::IPCThreadState::executeCommand
  libbinder        android::IPCThreadState::getAndExecuteCommand
  libbinder        android::IPCThreadState::joinThreadPool
  libutils         android::Thread::_threadLoop
  libandroid_runtime  android::AndroidRuntime::javaThreadShell

Our BASS_Init:

Code Select Expand

var sessionId = audioManager.GenerateAudioSessionId();
Bass.BASS_SetConfig((BASSConfig)62, sessionId);
Bass.BASS_Init(-1, 44100, (BASSInit)0x80000, IntPtr.Zero);

Have you seen this crash signature reported by other BASS Android users? If so, was anything specific found to mitigate it?                                                                                                                                                                         
                 
For an app like ours (long audiobook playback sessions with many sequential MP3 files), do you have a recommended pattern for BASS lifecycle on Android? We're not sure our current usage is ideal and would appreciate guidance.

[Ian @ un4seen]

I think there have a couple of reports of that crash. As you say, it appears to be an Android issue. It looks like this update may address it:

    https://android-review.googlesource.com/c/platform/frameworks/av/+/2909337

Of course, that won't help with older Android versions. I've never seen the crash myself, so haven't looked into possible workarounds. Are you able to reproduce it? If so, you could try using OpenSLES or AudioTrack output (instead of AAudio) and see if that helps. Otherwise you could check which are the most affected devices in your crash reports, and set one of them to use OpenSLES and another to use AudioTrack in your next release, and see if the crashing stops for either.

[b_kosmowski]

Hi Ian,

Thanks for the quick reply.
We haven't been able to reproduce the crash on our test devices, and our support team hasn't received any user-facing reports about it either. Given the high crash count vs. zero user complaints, it looks like this may be a silent background crash that doesn't visibly affect playback for end users.

For now we've decided to deprioritize the workarounds until we get a reproducible scenario or see user impact in support tickets. We'll keep your suggestions and revisit if the situation changes.
Thanks again for taking the time to look at this.

Błażej