iOS: failed engine restart after AVAudioEngineConfigurationChangeNotification is silently dropped, audio dead until manual rebuild

[marcospgp]

Description

When iOS posts AVAudioEngineConfigurationChangeNotification (a Bluetooth A2DP route renegotiation around screen lock is a reliable trigger), SystemNotificationManager's handleEngineConfigurationChange stops the engine, rebuilds the graph, and calls start again. If the app is locked with an input node attached, iOS refuses that restart, and the failure is just dropped: no retry, no error surfaced to JS. The engine stays dead after that, so recording, playback, and any keepalive source all go silent until the consumer tears the whole pipeline down and rebuilds it (we do this after the phone unlocks).

Whether it reproduces depends on whether the notification fires while a session is active, so identical test rounds pass or fail nondeterministically, which made this painful to pin down.

What we were hoping for: a failed config-change restart gets retried at the next opportunity (foreground, unlock, next route change), or at least surfaces to JS so the app can react. Right now the only signal is that audio stops.

Steps to reproduce

1. iOS app with an active playAndRecord session, an AudioRecorder recording, and an engine rendering output, with Bluetooth earphones connected.
2. Lock the phone mid-session with audio still running.
3. Wait for the route renegotiation (A2DP tends to do this around lock, but it is timing luck; several rounds may be needed).
4. When it fires while locked, the engine dies: no input, no output, no error. Unlock and the app has to rebuild everything itself.

Snack or a link to a repository

This is from a production voice app I can't share a runnable repro of, sorry. The failing path is readable in SystemNotificationManager.mm (handleEngineConfigurationChange: stop, rebuild, start, with the start failure unhandled). Happy to share device traces from our failing rounds if useful: we see Failed to start audio engine with session active and a route change reason=ConfigurationChange right after, zero interruption events.

React Native Audio API version

0.13.2

React Native version

0.86.0

Platforms

iOS

[marcospgp]

I went through the 0.13.2 sources to see whether any of this can be handled from the app side.

activelyReclaimSession(true) doesn't help. It only registers an AVAudioSessionSilenceSecondaryAudioHint observer and a 0.5s polling timer in SystemNotificationManager, so it never touches handleEngineConfigurationChange.

The restart does try to reactivate the session, so that's not the gap either. handleEngineConfigurationChange calls markInactive and then restartAudioEngine, and startEngine calls ensureActive:true itself before starting the engine. That leaves the refusal coming either from that activation failing while the screen is locked, or from startAndReturnError after it. Both only NSLog, which is why nothing reaches JS.

The handler right above it, handleMediaServicesReset, does markInactive, ensureActive:true, restartAudioEngine, while the config change handler skips the explicit reactivation and relies on the one inside startEngine.

The thing that mattered for us is the input node. The restart starts going through once the recorder is released, so on device we stop the recorder, start the engine, then reopen the mic, and skipping the stop walks straight back into the same refusal. A locked phone with a live input node attached looks like the case iOS won't start.

We're running a local patch that retries a refused restart on a backoff (2s doubling up to 32s, roughly 94 seconds before it stands down) plus a JS watchdog doing that stop, start, reopen cycle. We haven't seen a silent death since.

[closetcaiman]

Hi @marcospgp,

Thank you so much for a very detailed description and thorough investigation into this matter. Over the last days I've been trying to reproduce this on lock, but actually succeeded with AVAudioSessionInterruption (Siri) overlapping an AVAudioEngineConfigurationChangeNotification while on Bluetooth. I've got retry mechanism implemented which fixes the silent drop. Soon I'll able to open a PR. It's also worth to mention that handleEngineConfigurationChange was also touched in #1201, so probably it's best to test the nightly build once that PR is merged too.