subscriber: screen-share audio is forwarded into Discord voice (doubling / feedback loop) #142

New issue

Closed

opened 2026-10-01 15:49:03 +00:00 by robocub · 1 comment

robocub commented

2026-10-01 15:49:03 +00:00

Member

Symptom

When a Matrix participant in a bridged call shares their screen with audio (Element Call "Share screen" on a tab/window with audio), the bridge subscribes to the resulting screen-share audio track and plays it into the Discord voice channel through that participant's puppet, exactly like a microphone.

Observed on prod 2026-10-01 (Light Gaming): remote participant published a track ... kind=Audio → playback consumer started for the sharing participant → the shared audio was heard in Discord, doubled with its original source, and in one configuration fed back into itself (very loud echo for everyone in the channel until the share was stopped).

Expected

Screen-share audio must never be forwarded into Discord voice. Discord has no counterpart for a screen share (bots cannot stream, and Discord users watching a Go Live already hear it natively), so forwarding it only produces doubled audio or a feedback loop. Screen-share video is already dropped by the playback consumer (RemoteTrack::Video early return); audio needs the same treatment, keyed on the track source, not the kind.

Fix

In matrix-rtc/src/rtc/session.rs:

TrackPublished / TrackSubscribed: if publication.source() is TrackSource::Screenshare or TrackSource::ScreenshareAudio, log at info, set_subscribed(false), and skip the consumer + #73 heal-gate bookkeeping.
Keep microphone/unknown-source audio behaviour unchanged.

Related: a Matrix-side counterpart to #141 (excluded MXIDs that never get a puppet) would also stop a share-only participant from occupying a Discord puppet slot at all.

## Symptom When a Matrix participant in a bridged call shares their screen **with audio** (Element Call "Share screen" on a tab/window with audio), the bridge subscribes to the resulting screen-share audio track and plays it into the Discord voice channel through that participant's puppet, exactly like a microphone. Observed on prod 2026-10-01 (Light Gaming): `remote participant published a track ... kind=Audio` → `playback consumer started` for the sharing participant → the shared audio was heard in Discord, doubled with its original source, and in one configuration fed back into itself (very loud echo for everyone in the channel until the share was stopped). ## Expected Screen-share **audio** must never be forwarded into Discord voice. Discord has no counterpart for a screen share (bots cannot stream, and Discord users watching a Go Live already hear it natively), so forwarding it only produces doubled audio or a feedback loop. Screen-share **video** is already dropped by the playback consumer (`RemoteTrack::Video` early return); audio needs the same treatment, keyed on the track *source*, not the kind. ## Fix In `matrix-rtc/src/rtc/session.rs`: - `TrackPublished` / `TrackSubscribed`: if `publication.source()` is `TrackSource::Screenshare` or `TrackSource::ScreenshareAudio`, log at info, `set_subscribed(false)`, and skip the consumer + #73 heal-gate bookkeeping. - Keep microphone/unknown-source audio behaviour unchanged. Related: a Matrix-side counterpart to #141 (excluded MXIDs that never get a puppet) would also stop a share-only participant from occupying a Discord puppet slot at all.

robocub referenced this issue from a commit

2026-10-01 15:49:33 +00:00

fix(subscriber): never bridge screen-share media into Discord voice (#142)

robocub referenced this issue from a commit

2026-10-01 16:23:44 +00:00

fix(subscriber): never bridge screen-share media into Discord voice (#142)

robocub referenced this issue from a commit

2026-10-01 16:50:38 +00:00

Merge fix/skip-screenshare-audio: screen-share audio/video from Matrix is never bridged into Discord voice (#142)

robocub referenced this issue from a commit

2026-10-01 16:50:38 +00:00

release: 0.3.12 — screen-share media from Matrix is never bridged into Discord voice (#142)

robocub commented

2026-10-01 18:26:28 +00:00

Author

Member

Fixed in 7e04c78, shipped in v0.3.12, live-verified on prod 2026-10-01 18:23 UTC (Light Gaming):

a Matrix participant published a screen share with audio; prod logged remote participant published a track ... kind=Audio source=ScreenshareAudio → screen-share track — not bridged, unsubscribing (#142) → unsubscribe, and the same for the Screenshare video publication; no playback consumer was started for either.
Discord listeners in the channel confirmed the sharing participant's puppet stayed silent (no doubled audio).

Not covered here (expected): the participant's muted microphone track is still bridged, so a silent puppet still occupies a slot — that is the Matrix-side counterpart of #141.

Fixed in 7e04c78, shipped in **v0.3.12**, live-verified on prod 2026-10-01 18:23 UTC (Light Gaming): - a Matrix participant published a screen share with audio; prod logged `remote participant published a track ... kind=Audio source=ScreenshareAudio` → `screen-share track — not bridged, unsubscribing (#142)` → unsubscribe, and the same for the `Screenshare` video publication; no playback consumer was started for either. - Discord listeners in the channel confirmed the sharing participant's puppet stayed silent (no doubled audio). Not covered here (expected): the participant's muted *microphone* track is still bridged, so a silent puppet still occupies a slot — that is the Matrix-side counterpart of #141.

robocub closed this issue

2026-10-01 18:26:28 +00:00