fix(client): prevent screen share audio loopback by default#2226
Conversation
Enable AEC on the default screen share audio constraints so that remote participants' voices played through the local speakers are subtracted from the captured system audio before publish. Also align the default ScreenShareState audio bitrate profile with the capture path: switch from MUSIC_HIGH_QUALITY to VOICE_HIGH_QUALITY so the declared profile honestly describes what is being captured. Music sharing remains supported via an explicit setAudioBitrateProfile(MUSIC_HIGH_QUALITY) call when HIFI is enabled at the call level.
|
📝 WalkthroughWalkthroughSwitches screen-share audio bitrate profile from MUSIC_HIGH_QUALITY to VOICE_HIGH_QUALITY, enables echo cancellation and ChangesScreen Share Audio Configuration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Set restrictOwnAudio: true on the default screen share audio constraints so that audio originating from the capturing tab (notably WebRTC <audio> elements rendering remote participants) is filtered out at the source before publish. Complements the AEC default for the system-audio capture path. Browsers without support for the constraint silently ignore it.
💡 Overview
When a user shares system audio while in a call, the OS-mixed system audio also includes the remote participants' voices coming out of the local speakers. This currently produces an unpleasant loopback for the remote speakers (they hear themselves played back through the screen share track).
This change updates the screen share audio defaults so AEC removes the call audio from the captured system audio by default, while preserving the rest (music, video, presentation audio).
📝 Implementation notes
echoCancellationtotrueingetScreenShareStream's default audio constraintsrestrictOwnAudiofor browsers that support itScreenShareState's defaultaudioBitrateProfilefromMUSIC_HIGH_QUALITYtoVOICE_HIGH_QUALITY. The previous default was inconsistent with what the capture path actually produces.options.audiolast, so any explicit override, including the constraints written bysetAudioBitrateProfile(MUSIC_HIGH_QUALITY)continues to win, preserving HIFI music quality when the integrator opts in.🎫 Ticket: https://linear.app/stream/issue/REACT-973/feedback-loop-issue-with-chromes-new-system-audio-sharing-feature