Audioserver crash loop (WebRTC/AAudio MMAP) on Volla Phone Quintus during/after calls

Device: Volla Phone Quintus, Android 15 (VollaOS build 134-volla-15.0, security patch 2026-05-01)
App: Nextcloud Talk 24.0.2 (Aurora Store) — same behavior with the previous version too
Server: Nextcloud 34.0.1.2, Talk (spreed) 24.0.2, external signaling backend (self-hosted HPB, nextcloud-spreed-signaling)

Symptom: mid-call, the other participant stopped hearing any audio (mic appeared unmuted in the UI, nothing transmitted). The call then dropped, and afterwards the app crashed/failed on every subsequent launch, even without starting a call.

Root cause found via adb logcat: the system audioserver process enters a continuous crash loop as soon as libjingle_peerconnection_so.so loads / the WebRTC audio engine initializes:

E AudioSystem-JNI: Command failed for android_media_AudioSystem_checkAudioFlinger: -32
E AS.AudioService: Audioserver died.

repeating every ~500ms indefinitely. dumpsys media.audio_flinger confirms the service is unreachable system-wide while in this state — not app-scoped. Force-stopping the app does not help; only a full device reboot restores audio.

aaudio.mmap_policy=2 (AUTO) / aaudio.mmap_exclusive_policy=2 on this device — suspect the low-latency AAudio MMAP path is hitting an audio HAL bug on this device's driver (cf. known AAudio MMAP HAL instability: google/oboe#2025, google/oboe#724). Device is a user build with adb root disabled, so we couldn't test forcing aaudio.mmap_policy=1 (NEVER) to confirm.

Would it be feasible for the app's WebRTC audio device module to catch AudioFlinger disconnects more gracefully, or expose a setting to force the legacy (non-MMAP) audio path for devices with this kind of HAL instability?

Steps to reproduce:

1. Join/start a Talk call on the device above
2. Talk for a while — at some point the remote participant stops receiving audio, though the local mic still shows as unmuted
3. Call eventually drops
4. App subsequently crashes/fails to work on every launch (even without a call) until the device is rebooted

No source file or test is named; the issue points to the app's WebRTC audio device module. Start by reproducing the failure with adb logcat and dumpsys media.audio_flinger, then determine whether the disconnect can be handled in the module or whether a legacy non-MMAP option is feasible. Done should include an agreed, testable behavior for this device failure.