Fix inconsistent participant audio delivery
- Dominant language
- TypeScript
- Stars
- 36
- Forks
- 22
- PR merge metrics
- No merged PRs in 30d
Description
## Overview
A meeting participant can be audible to only a subset of attendees, creating inconsistent audio delivery within the same call.
## Issue type
Bug report
## Details
During a live meeting, Somyadeep asked whether he was audible. Some participants confirmed they could hear him, while Abhyuday noted that he was audible for some people but not others. The product should reliably deliver a participant's audio consistently to all connected attendees and provide actionable diagnostics when delivery fails for a subset.
## Steps to reproduce
1. Join a meeting with multiple attendees.
2. Have one participant speak using their microphone.
3. Observe that some attendees can hear the speaker while others cannot.
## Expected behavior
If a participant's microphone is active and their audio stream is successfully published, all eligible attendees in the meeting should receive and hear it consistently; failures should be surfaced with useful status or recovery guidance.
## Actual behavior
The same speaker is audible to some attendees but inaudible to others in the same meeting.
## Acceptance criteria
- [ ] Audio from an active participant is delivered consistently to all eligible meeting attendees.
- [ ] The client detects and reports partial audio-subscription or playback failures.
- [ ] Users are given a clear recovery path when partial audio delivery is detected.
- [ ] Automated coverage includes a multi-attendee scenario that verifies all attendees receive a published audio stream.
## Additional context
Meeting transcript around 16:43:33–16:44:01: Somyadeep asked if he was audible; Abhyuday said he was audible for some people and not others. Chat participants also reported mixed results.
_Created by the Conclave in-meeting assistant._
Contributor guide
Research direction
Start by tracing audio publication, subscription, playback, and failure reporting across the web/mobile clients, SFU, and apps SDK. Reproduce the multi-attendee scenario described in the issue and identify the entry points responsible for delivery and diagnostics. Done means all eligible attendees receive the stream, partial failures are reported with recovery guidance, and automated coverage verifies the scenario.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- audio-video-rtc
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100