Describe the bug
When receiving audio from a remote participant (browser → Android), the audio is severely distorted with a distinctive "chi-chu-cha" robotic/clicking sound pattern. Upstream audio (Android → browser) works correctly.
The same test setup works perfectly with Jitsi Meet (same WebRTC/Opus technology), confirming the issue is specific to the LiveKit Android SDK's audio handling layer.
To Reproduce
- Create a LiveKit room on LiveKit Cloud
- Join the room from a desktop browser (Chrome or Firefox) with microphone enabled
- Join the same room from an Android device using the LiveKit Android SDK
- Speak from the browser
- Listen on the Android device - audio is distorted with robotic "chi-chu-cha" pattern
Expected behavior
Clear audio playback on the Android device, matching the quality of the original browser audio.
Screenshots
N/A - Audio issue (no visual component)
Device Info:
- Device: Custom Android headset device + Windows Android Emulator (both affected)
- OS: Android (API level 30+)
Dependencies Info:
- client-sdk-android: v2.x (latest)
- LiveKit Server: LiveKit Cloud (wss://*.livekit.cloud)
Additional context
Diagnostic Data:
- Packet loss: 0%, Jitter: 2-5ms, Concealment events: 0 (network is fine)
- Sample rate switches from 16kHz → 48kHz during initialization
- Asymmetric audio amplitude: Max +32256, Min -32768 (suggests byte-level corruption)
- ~53% zero samples, ~50% samples clipping at ±32710
Fixes Attempted (all failed):
- Disable hardware AEC/NS:
setUseHardwareAcousticEchoCanceler(false)
- Switch to
MediaAudioType() instead of CallAudioType()
- Force 48kHz:
setInputSampleRate(48000), setOutputSampleRate(48000)
- Bypass render processing:
AudioProcessorOptions(renderPreBypass = true)
- Gain reduction via custom
AudioProcessorInterface
- Custom
JavaAudioDeviceModule to bypass all LiveKit audio handling
Jitsi Comparison:
Tested identical audio path using Jitsi Meet (https://meet.jit.si)/ - audio is perfectly clear. Since Jitsi uses the same WebRTC/Opus/libwebrtc stack, this confirms the bug is within LiveKit's audio processing layer.
Related Issues:
Describe the bug
When receiving audio from a remote participant (browser → Android), the audio is severely distorted with a distinctive "chi-chu-cha" robotic/clicking sound pattern. Upstream audio (Android → browser) works correctly.
The same test setup works perfectly with Jitsi Meet (same WebRTC/Opus technology), confirming the issue is specific to the LiveKit Android SDK's audio handling layer.
To Reproduce
Expected behavior
Clear audio playback on the Android device, matching the quality of the original browser audio.
Screenshots
N/A - Audio issue (no visual component)
Device Info:
Dependencies Info:
Additional context
Diagnostic Data:
Fixes Attempted (all failed):
setUseHardwareAcousticEchoCanceler(false)MediaAudioType()instead ofCallAudioType()setInputSampleRate(48000),setOutputSampleRate(48000)AudioProcessorOptions(renderPreBypass = true)AudioProcessorInterfaceJavaAudioDeviceModuleto bypass all LiveKit audio handlingJitsi Comparison:
Tested identical audio path using Jitsi Meet (https://meet.jit.si)/ - audio is perfectly clear. Since Jitsi uses the same WebRTC/Opus/libwebrtc stack, this confirms the bug is within LiveKit's audio processing layer.
Related Issues: