From ea579cb998bfb2b1ecd09bf9c8bb51e4fda76151 Mon Sep 17 00:00:00 2001 From: Lotus CI Date: Fri, 18 Sep 2026 23:54:25 -0400 Subject: [PATCH] =?UTF-8?q?fix(lotus):=20screenshare-audio=20mute=20surviv?= =?UTF-8?q?es=20a=20re-share=20=E2=80=94=20mute=20via=20the=20renderer,=20?= =?UTF-8?q?not=20setVolume?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit "Mute Screenshare Audio" (io.lotus.set_deafen screenshareAudioMuted) used RemoteParticipant.setVolume(0, ScreenShareAudio). EC's own createVolumeControls writes volume 1 through the same setter the moment a new screenshare media item resolves, so when the sharer stopped and re-shared (or a late joiner shared) the audio came back at full volume while the host button still said "Unmute Screenshare Audio". Reproduced on the local calls stack with two headless clients: after a re-share the screen_share_audio element read vol=1. Now the flag is a global behavior (muteScreenshareAudio$) that LivekitRoomAudioRenderer turns into the `muted` prop of every Track.Source.ScreenShareAudio element — the exact mechanism deafen already uses (pub.setEnabled(false): the server stops sending). Verified via the RemoteTrackPublication behind each