We did some research, so I want to share the results with you. I hope it will help you investigate the problem.
The previous callstack seems to be wrong. The correct one looks like this:
#0: libfmod.so+0xd73e8 // seems to be OutputRingBuffer::read( 0xb400007155bca800, 0x0, 0x240, true)
#1: libfmod.so+0xe8df8 // seems to be OutputOpenSL::feederThread
#2: libwilhelm.so`audioTrack_handleMoreData_lockPlay(CAudioPlayer_struct*, android::AudioTrack::Buffer const&) + 136
#3: libwilhelm.so`android::AudioTrackCallback::onMoreData(android::AudioTrack::Buffer const&) + 52
#4: libaudioclient.so`android::AudioTrack::processAudioBuffer() + 3048
#5: libaudioclient.so`android::AudioTrack::AudioTrackThread::threadLoop() + 300
#6: libutils.so`android::Thread::_threadLoop(void*) + 428
#7: libandroid_runtime.so`android::AndroidRuntime::javaThreadShell(void*) + 148
#8: libc.so`__pthread_start(void*) + 212
#9: libc.so`__start_thread + 72
Recently, we made a change in our code. Now, we call _lowLevelSystem->setOutput(FMOD_OUTPUTTYPE_NOSOUND) when the application goes on pause, and _lowLevelSystem->setOutput(FMOD_OUTPUTTYPE_OPENSL) when the application resumes. After this change, this occurs more often. As I mentioned before, it seems that the crash occurs after losing the audio context, suggesting a connection between these two things.