iOS: deadlock (0x8BADF00D watchdog) with iosVoiceProcessing=true — handleEngineConfigurationChange isInUse vs AVAudioEngine dealloc dispatch_sync (nightly)

[antoniosb]

Summary

With new AudioRecorder({ iosVoiceProcessing: true }) on the current nightly, the app deadlocks on the main thread as soon as playback starts through an AudioContext, and iOS kills it with watchdog code 0x8BADF00D ("scene-update watchdog transgression … is stuck (deadlock)").

The crash report shows a lock-order inversion between the engine-configuration-change handler and the engine rebuild. PR #1290 ("fix(ios): engine-worker deadlock") moves the isInUse check inside the main-queue block, which is exactly the ordering in this trace — this issue is filed so that PR has something to close, and to add a reproducible stack.

Environment

• react-native-audio-api 1.0.0-nightly-1966b4a-20260918 (audio-api-nightly dist-tag)
• React Native 0.86.3, Expo SDK 57 (dev-client build, new architecture)
• iOS 26.6.2, iPhone 13 Pro (iPhone14,2), Xcode 27.0 (27A266a)
• Does not reproduce on 0.13.4 (which has no iosVoiceProcessing option) with the same JS.

Repro

AudioManager.setAudioSessionOptions({
  iosCategory: "playAndRecord",
  iosMode: "voiceChat",
  iosOptions: ["defaultToSpeaker", "allowBluetoothHFP"],
});
await AudioManager.setAudioSessionActivity(true);

const rec = new AudioRecorder({ iosVoiceProcessing: true, androidInputPreset: "voiceCommunication" });
rec.onAudioReady({ sampleRate: 16000, bufferLength: 640, channelCount: 1 }, (ev) => {
  /* Float32 → Int16 → WebSocket */
});
await rec.start(); // → {"status":"success"}

// Later, when the first remote PCM chunk arrives:
const ctx = new AudioContext({ sampleRate: 24000 });
const buf = ctx.createBuffer(1, samples, 24000);
// ... copyToChannel, createBufferSource, start()

Sequence observed: recorder starts fine → first TTS chunk arrives → AudioContext is created and a buffer scheduled → UI freezes → ~10 s later the watchdog kills the process.

Voice-processing IO changes the IO unit configuration, so AVAudioEngineConfigurationChangeNotification fires while the engine is being (re)built.

Crash report (excerpt)

Termination: FRONTBOARD 0x8BADF00D — scene-update watchdog transgression: app<me.duoai.mobilepoc> is stuck (deadlock)

Thread 0 (main, triggered):

libsystem_kernel   kevent_id
libdispatch        _dispatch_kq_poll
libdispatch        _dispatch_event_loop_wait_for_ownership
libdispatch        __DISPATCH_WAIT_FOR_QUEUE__
libdispatch        _dispatch_sync_f_slow
AVFAudio           -[AVAudioEngine dealloc]
app                -[AudioEngine setAudioEngine:]
app                -[AudioEngine destroyAudioEnginePreservingSessionDeactivationState:]
app                -[AudioEngine rebuildAudioEngine]
app                -[AudioEngine rebuildAudioEngineAndResumeIfNeeded]
app                -[AudioEngine restartAudioEngine]
app                __61-[SystemNotificationManager handleEngineConfigurationChange:]_block_invoke
libdispatch        _dispatch_main_queue_drain

Thread "engine":

libsystem_kernel   __psynch_mutexwait
libc++             std::recursive_mutex::lock()
app                std::scoped_lock<std::recursive_mutex>::scoped_lock
app                -[AudioEngine isInUse]
app                -[SystemNotificationManager handleEngineConfigurationChange:]
CoreFoundation     __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__
Foundation         -[NSNotificationCenter postNotificationName:object:userInfo:]
AVFAudio           AVAudioEngineImpl::IOUnitConfigurationChanged() block
libdispatch        _dispatch_source_invoke / _dispatch_lane_serial_drain

Main holds the engine recursive_mutex and dispatch_syncs onto the engine queue from -[AVAudioEngine dealloc]; the engine queue is blocked in isInUse waiting for that same mutex.

Full .ips available on request.

[antoniosb]

Follow-up: I applied the one-hunk change from #1290 locally (moving the isInUse check inside the main-queue block) and rebuilt. The original inversion is gone, but the app still hangs and is killed by the watchdog, now at a different place:

Thread 0 (main):

libsystem_kernel        mach_msg2_trap
libEmbeddedSystemAUs    AURemoteIO::Initialize()
libEmbeddedSystemAUs    ausdk::AUBase::DoInitialize()
AudioToolboxCore        AudioUnitInitialize
AudioToolboxCore        -[AUAudioUnitV2Bridge allocateRenderResourcesAndReturnError:]
AVFAudio                AVAudioIONodeImpl::GetOutputFormat(unsigned long)
AVFAudio                -[AVAudioNode outputFormatForBus:]
AVFAudio                -[AVAudioIONode setVoiceProcessingEnabled:error:]
app                     -[AudioEngine applyVoiceProcessing]
app                     -[AudioEngine materializeTrackedNodesIfNeeded]
app                     -[AudioEngine rebuildAudioEngine]
app                     -[AudioEngine rebuildAudioEngineAndResumeIfNeeded]
app                     -[AudioEngine restartAudioEngine]

JS thread: blocked on the engine recursive_mutex in -[AudioEngine isEngineRunning] ← IOSAudioPlayer::isRunning() ← AudioContext::isDriverRunning() ← AudioParam::scheduleAudioEvent (an AudioParam.value = assignment from JS).

Termination reason this time: 0x8BADF00D … Failed to terminate gracefully after 5.0s.

Reading: setVoiceProcessingEnabled: itself changes the IO unit configuration, which posts AVAudioEngineConfigurationChangeNotification, which calls restartAudioEngine → rebuildAudioEngine → applyVoiceProcessing → setVoiceProcessingEnabled: again, all while holding the engine mutex on the main thread and with AURemoteIO::Initialize waiting on the audio server. So #1290 fixes the first inversion, but the voice-processing path also needs to (a) not re-apply voice processing from inside the config-change rebuild when it is already enabled, and (b) not hold the engine mutex across setVoiceProcessingEnabled:.

Same environment as above (nightly 1.0.0-nightly-1966b4a-20260918, RN 0.86.3, iOS 26.6.2, iPhone 13 Pro). Repro is identical: new AudioRecorder({ iosVoiceProcessing: true }) + an AudioContext scheduling buffers.

[closetcaiman]

Hi @antoniosb, thank you so much for both reports (especially for the second one). I'm working on the fix now and hope to have the PR ready soon.