rtc: LiveKit ConnectionQuality + RTC stats logging (packet-loss visibility) #116

New issue

Open

opened 2026-07-13 16:29:56 +00:00 by robocub · 1 comment

robocub commented

2026-07-13 16:29:56 +00:00

Collaborator

Gap: the bridge is blind to loss/jitter on the LiveKit leg. The Discord leg has proxies (shape_warns PLC-frame counter, jitter_dropped), but we handle no ConnectionQuality events and read no RTC stats from the SFU — so per-participant link quality between clients/bridge and LiveKit is invisible.

Cost of the gap (real case, 2026-07-13): a beta user reported choppy audio; bridge-side metrics were all clean (jitter_dropped=0, capture_errs=0, steady voicetick), so the client↔SFU leg could only be inferred by elimination. ConnectionQuality events would have answered it with data.

Proposal:

Subscribe to the livekit-rust SDK's ConnectionQualityChanged events in rtc::session (subscriber) and rtc::ghost (publishers); log quality transitions per participant identity (rate-limited INFO, WARN on Poor).
Periodically sample RTC stats for subscribed tracks (packet loss %, jitter) into the existing ~5s "audio health" log line.
Keys off existing log-based ops (nvb-watch) — no new infra. Feeds the future /metrics exporter (see the Prometheus issue).

**Gap:** the bridge is blind to loss/jitter on the LiveKit leg. The Discord leg has proxies (`shape_warns` PLC-frame counter, `jitter_dropped`), but we handle no `ConnectionQuality` events and read no RTC stats from the SFU — so per-participant link quality between clients/bridge and LiveKit is invisible. **Cost of the gap (real case, 2026-07-13):** a beta user reported choppy audio; bridge-side metrics were all clean (`jitter_dropped=0`, `capture_errs=0`, steady voicetick), so the client↔SFU leg could only be *inferred by elimination*. `ConnectionQuality` events would have answered it with data. **Proposal:** - Subscribe to the livekit-rust SDK's `ConnectionQualityChanged` events in `rtc::session` (subscriber) and `rtc::ghost` (publishers); log quality transitions per participant identity (rate-limited INFO, WARN on `Poor`). - Periodically sample RTC stats for subscribed tracks (packet loss %, jitter) into the existing ~5s "audio health" log line. - Keys off existing log-based ops (nvb-watch) — no new infra. Feeds the future `/metrics` exporter (see the Prometheus issue).

robocub referenced this issue from a commit

2026-07-13 18:36:21 +00:00

feat(rtc): log LiveKit ConnectionQuality per participant (#116)

robocub referenced this issue from a commit

2026-07-13 18:37:42 +00:00

feat(rtc): log LiveKit ConnectionQuality per participant (#116)

robocub referenced this issue

2026-07-14 20:49:25 +00:00

feat(rtc): log LiveKit ConnectionQuality per participant (#116) #122

robocub referenced this issue from a commit

2026-07-14 20:49:41 +00:00

Merge pull request 'feat(rtc): log LiveKit ConnectionQuality per participant (#116)' (#122) from feat/116-connection-quality into master

robocub referenced this issue

2026-07-14 20:51:19 +00:00

e2e/staging post-mortem: 4 red nightlies (apt-daily contention) + a stale-fingerprint frankenbuild that faked a d2m regression #123

robocub commented

2026-07-14 20:51:19 +00:00

Author

Collaborator

Phase 1 (ConnectionQualityChanged events, WARN on Poor/Lost) merged in PR #122, shipped in v0.3.0. Keeping open for the second half: periodic RTC stats sampling (loss %/jitter) folded into the 5s audio-health line.