Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Audio routes through call speaker instead of media speaker when joining as a viewer-only participant

Open
  • Is something wrong?
#1,063 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
flutter
Domain
audio-video-rtc, mobile

Research direction

Start by reading the audio-routing setup around RoomOptions and Hardware.instance, then trace how the SDK handles audio sessions on Android and iOS when a viewer joins without publishing tracks. The issue does not name files or tests, so first locate those entry points and relevant platform tests. Done means receive-only participants use media playback routing without breaking audio for participants who publish tracks.

Written by the indexing model from the issue text.

Description

Is your feature request related to a problem? Please describe.
When joining a livestream session as a pure viewer (no microphone, no camera), the audio is incorrectly routed through the device's call/earpiece speaker instead of the media/loudspeaker — the same routing used for phone calls.

This occurs even though the viewer is not publishing any audio or video track. The expected behavior is that a participant in a receive-only role should use media playback audio routing, consistent with how any video player or media app behaves. Instead, LiveKit appears to initialize WebRTC in MODE_IN_COMMUNICATION (Android) / AVAudioSessionCategory.playAndRecord (iOS) regardless of whether the local participant is actually publishing.

Describe the solution you'd like
When a participant joins with no published tracks (viewer-only / subscriber-only role), LiveKit should automatically apply media playback audio routing:

• Android: Use AudioManager.MODE_NORMAL with loudspeaker, not MODE_IN_COMMUNICATION
• iOS: Use AVAudioSessionCategory.playback instead of playAndRecord

Ideally, expose a participant role hint (e.g. ParticipantKind.viewer or a audioMode option in RoomOptions) so developers can explicitly declare the intended audio routing behavior at connection time, before WebRTC initializes the audio session.

Describe alternatives you've considered
• Calling Hardware.instance.setSpeakerphoneOn(true) before room.connect() — overridden internally when WebRTC initializes the audio session on first track subscription.

• Manually reconfiguring AudioSession after the first remote audio track is subscribed — partially works but requires a delay and is fragile, as LiveKit re-acquires the audio session asynchronously.

• Using AudioOutputOptions(speakerOn: true) in RoomOptions — does not change the underlying audio mode from communication to media playback.

Additional context
• SDK: livekit_client (Flutter)
• Platforms affected: Android & iOS
• Use case: Livestreaming with a single host and many viewer-only participants
• Root cause: WebRTC initializes the audio stack in voice communication mode unconditionally, even for receive-only participants. This is by design in WebRTC but should be overridden by LiveKit when no local tracks are published.

Dominant language
Dart
Stars
421
Forks
260
Avg merge
3d 9h
Merged PRs (30d)
11

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from livekit/client-sdk-flutter

All issues in livekit/client-sdk-flutter

Similar issues

More Dart issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.