libwilhelm is being sent audio after a mutex has been poisoned

I got this crash/stacktrace while vibecoding cemu on the discord

fault=0x55555555555565 pc=0x797613d6fc lr=0x797649211c sp=0x76b4dd43c0
thread: AudioTrack
  pc in 7976110000-79761a7000 r-xp 00044000 07:150 24                            /apex/com.android.runtime/lib64/bionic/libc.so (+0x2d6fc)
  lr in 7976487000-79764aa000 r-xp 0001c000 fe:0e 59360138                       /system/lib64/libwilhelm.so (+0xb11c)
  fault in unmapped
guest: no PPC instance on this thread
Error: signal 11:
#00 0x0000007578991760  /data/data/com.retroarch/cores/cemu_libretro_android.so+0xe8f760
#01 0x000000795e2660a4  /apex/com.android.art/lib64/libsigchain.so+0x70a4  _ZN3art11SignalChain7HandlerEiP7siginfoPv+0x484
#02 0x000000799879e848  [vdso]+0x848  __kernel_rt_sigreturn+0x0
#03 0x000000797613d6fc  /apex/com.android.runtime/lib64/bionic/libc.so+0x716fc  pthread_mutex_lock+0xc
#04 0x000000797649211c  /system/lib64/libwilhelm.so+0x2711c
#05 0x000000797649211c  /system/lib64/libwilhelm.so+0x2711c
#06 0x000000797648e52c  /system/lib64/libwilhelm.so+0x2352c
#07 0x0000007962d3476c  /system/lib64/libaudioclient.so+0xb076c  _ZN7android10AudioTrack18processAudioBufferEv+0xbac
#08 0x0000007962d33810  /system/lib64/libaudioclient.so+0xaf810  _ZN7android10AudioTrack16AudioTrackThread10threadLoopEv+0x130
#09 0x0000007989a62dc4  /system/lib64/libutils.so+0x16dc4  _ZN7android6Thread11_threadLoopEPv+0x174
#10 0x000000796b543370  /system/lib64/libandroid_runtime.so+0xf1370  _ZN7android14AndroidRuntime15javaThreadShellEPv+0x90
#11 0x000000797613c1d8  /apex/com.android.runtime/lib64/bionic/libc.so+0x701d8
#12 0x000000797612d564  /apex/com.android.runtime/lib64/bionic/libc.so+0x61564

After some back and forth with the AI, it claims its not their fault (ofc) because it claims there is no audio to be prevented from being sent after retroarch closes the audio. The core line on the start is a crash handler installed exactly to print crashes to log.

(The audio callback used retro_set_audio_sample_batch is guarded against sending more audio in retro_unload_game with a atomic set at the start of that function)

This is the quote that convinced me to report this:

Neither will fix it, and the reason is in our own call graph: s_audio_callback has one caller, LibretroAudioAPI::FlushAudio, and that is called from two places, both inside retro_run (CemuLibretro.cpp:4828 and 4919). RetroArch calls retro_unload_game on that same thread, so when unload starts the in-flight count is structurally zero. The counter waits for nothing, and an unconditional 2s would too - it would only add 2s to every close. That it crashed again on 66daf51d fits that exactly.
Who it actually is: libwilhelm and AudioTrack::processAudioBuffer on the stack, with a mutex overwritten by the 0x5555 poison. ENABLE_CUBEB is forced OFF for libretro builds (CMakeLists.txt:216-218), so nothing of ours creates an AudioTrack - that object is RetroArch's own OpenSL driver freeing its lock under its own callback thread. Which is why nothing of ours is on the stack

Start with CemuLibretro.cpp at the FlushAudio call sites around lines 4828 and 4919, then trace retro_unload_game and retro_set_audio_sample_batch. Check CMakeLists.txt lines 216-218 to confirm the libretro audio configuration and inspect how RetroArch's Android OpenSL driver handles its AudioTrack callback during unload. Done means the crash is reproduced and the audio lifetime issue is identified and fixed or clearly isolated.