You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fixed ScreenAudioCapturer crash, stale audio replay, and AudioRecord leak (#982)
* Fixed ScreenAudioCapturer audio thread crash and stale audio replay after MediaProjection stops
* Fixed AudioRecord leak when releaseAudioResources races initAudioRecord
initAudioRecord runs on WebRTC's audio record thread, while
releaseAudioResources is called by the app from a thread of its choosing.
A release landing between AudioRecord creation and its assignment to the
field saw a null audioRecord, did nothing, and left init to publish a
recording AudioRecord that nothing owned.
Publication and release now share a lock, and a released capturer stays
released, so an init that finishes after a release discards its
AudioRecord instead of stranding it. Leaked recorders hold the playback
capture input open: with 100 racing release/init pairs on an Android 17
emulator, 9 recorders were stranded and the remaining 91 creation
attempts failed with "could not open input for device
AUDIO_DEVICE_IN_REMOTE_SUBMIX". After the fix all 100 discard cleanly and
no creation fails.
* Validated channel count and simplified the min buffer size check in initAudioRecord
Fix `ScreenAudioCapturer` crashing the audio thread when its `MediaProjection` is revoked (for example via the system "stop sharing" chip) before the first microphone buffer arrives. `initAudioRecord` now returns false when the `AudioRecord` cannot be created instead of throwing inside WebRTC's audio record thread, where an unhandled exception kills the process; only `startRecording()` was guarded before. `AudioRecord.read` failures are also handled now: the return value was ignored, so once the projection died the buffer's stale contents (the last captured frame) were mixed into the microphone track on every callback, an audible loop until the callback was detached. On a read error the capturer releases its `AudioRecord` and degrades to mic-only audio.
6
+
7
+
`releaseAudioResources` is also safe to call while `initAudioRecord` is still running. It runs on the app's thread while init runs on the audio record thread, and it used to observe a null `audioRecord` and do nothing, so the recorder that init went on to publish stayed running until finalization. Leaked recorders hold the playback capture input open, and later capture attempts fail once enough of them accumulate.
0 commit comments