Hi,
wondering if you've ever run into a deadlock related to the willEnableEngine / willDisableEngine blocking delegate pattern in combination with a manual audio session setup.
Background
We're using autoConfigureAudioSession: false and configuring the audio session manually in onAudioSessionActivated (via setAppleAudioConfiguration) rather than responding to the willEnableEngine hook. Because onAudioSessionActivated fires before setEngineAvailability(default) is ever called, the session is already in its correct state by the time any delegate fires.
What we've observed is that willEnableEngine fires twice during a typical call setup:
- Once at the initial engine start (playout-only, recording off - peer connection not yet established)
- Again at
PC→CONNECTED, when WebRTC adds the local audio capture path and forces a stop/restart of the AVAudioEngine to go from output-only to full-duplex
Because the library holds the thread while waiting for a JS response, and because the second willEnableEngine fires during an internal WebRTC reconfiguration that's racing with trackSubscribed processing, we end up in a window where the audio module mutex is held longer than necessary - and in some cases this manifests as a freeze/deadlock.
Our current conclusion
For architectures that opt out of setupIOSAudioManagement and pre-configure the session externally, responding with 0 immediately from willEnableEngine is the correct behaviour- the blocking wait has no observable benefit since there's no session configuration left to do. The fire-and-forget matches the observable result of a 0ms JS response, without holding the mutex.
The deeper fix we're considering is deferring setEngineAvailability(default) until after the room is fully connected (post-PC→CONNECTED), so the engine starts once in its final playout: 1, recording: 1 state and the stop/restart cycle never happens during active call setup.
Have you seen anything like this in your own testing or from community reports?
Hi,
wondering if you've ever run into a deadlock related to the
willEnableEngine/willDisableEngineblocking delegate pattern in combination with a manual audio session setup.Background
We're using
autoConfigureAudioSession: falseand configuring the audio session manually inonAudioSessionActivated(viasetAppleAudioConfiguration) rather than responding to thewillEnableEnginehook. BecauseonAudioSessionActivatedfires beforesetEngineAvailability(default)is ever called, the session is already in its correct state by the time any delegate fires.What we've observed is that
willEnableEnginefires twice during a typical call setup:PC→CONNECTED, when WebRTC adds the local audio capture path and forces a stop/restart of theAVAudioEngineto go from output-only to full-duplexBecause the library holds the thread while waiting for a JS response, and because the second
willEnableEnginefires during an internal WebRTC reconfiguration that's racing withtrackSubscribedprocessing, we end up in a window where the audio module mutex is held longer than necessary - and in some cases this manifests as a freeze/deadlock.Our current conclusion
For architectures that opt out of
setupIOSAudioManagementand pre-configure the session externally, responding with0immediately fromwillEnableEngineis the correct behaviour- the blocking wait has no observable benefit since there's no session configuration left to do. The fire-and-forget matches the observable result of a 0ms JS response, without holding the mutex.The deeper fix we're considering is deferring
setEngineAvailability(default)until after the room is fully connected (post-PC→CONNECTED), so the engine starts once in its finalplayout: 1, recording: 1state and the stop/restart cycle never happens during active call setup.Have you seen anything like this in your own testing or from community reports?