Screen share with audio on Linux and Windows #4

New issue

Open

opened 2026-10-04 20:18:48 +00:00 by robocub · 0 comments

robocub commented

2026-10-04 20:18:48 +00:00

Owner

Why

Streaming a game or a video with its sound is a core Discord habit, and a common reason people say they can't switch (Commet #969 says exactly that).

What exists

Video only. matrix_livekit_voip_session.dart builds ScreenShareCaptureOptions with source, framerate and bitrate, and publishes one video track. No audio is captured or published.

Plan

Windows: WASAPI loopback of the default output device. This is what Chromium does for screen-share audio on Windows.
Linux: PipeWire. The screencast portal provides video only, so audio needs its own capture: either the sink monitor (whole system) or a per-application node (better). Vencord's venmic shows the per-app approach.
Publish as a separate audio track with LiveKit source screenShareAudio so Element Call and other clients treat it as stream audio, not as a second microphone.
Echo: whole-system loopback includes the call itself, so everyone would hear themselves back. Either capture a single application, or exclude the app's own output stream. This must be solved before shipping.
A toggle in the source picker: "Share audio".

Notes

This also touches the forked flutter-webrtc / LiveKit SDK, like voice isolation.
The Nether voice bridge does not forward screen shares to Discord today; stream audio would need its own bridge work.

Acceptance

Share a browser playing a video on Linux (PipeWire) and on Windows. Element Call on another machine hears the video's audio in sync. Nobody hears their own voice echoed back.

Filed with LLM assistance. This is a fork-only issue; never refile it on Commet's tracker.

## Why Streaming a game or a video with its sound is a core Discord habit, and a common reason people say they can't switch (Commet #969 says exactly that). ## What exists Video only. `matrix_livekit_voip_session.dart` builds `ScreenShareCaptureOptions` with source, framerate and bitrate, and publishes one video track. No audio is captured or published. ## Plan - **Windows:** WASAPI loopback of the default output device. This is what Chromium does for screen-share audio on Windows. - **Linux:** PipeWire. The screencast portal provides video only, so audio needs its own capture: either the sink monitor (whole system) or a per-application node (better). Vencord's venmic shows the per-app approach. - Publish as a separate audio track with LiveKit source `screenShareAudio` so Element Call and other clients treat it as stream audio, not as a second microphone. - **Echo:** whole-system loopback includes the call itself, so everyone would hear themselves back. Either capture a single application, or exclude the app's own output stream. This must be solved before shipping. - A toggle in the source picker: "Share audio". ## Notes - This also touches the forked flutter-webrtc / LiveKit SDK, like voice isolation. - The Nether voice bridge does not forward screen shares to Discord today; stream audio would need its own bridge work. ## Acceptance Share a browser playing a video on Linux (PipeWire) and on Windows. Element Call on another machine hears the video's audio in sync. Nobody hears their own voice echoed back. --- _Filed with LLM assistance. This is a fork-only issue; never refile it on Commet's tracker._

robocub added the

feature

voice

effort: large

labels

2026-10-04 20:18:48 +00:00