Hi
# ask-ait
tall-businessperson-30911
02/16/2026, 9:24 AMHi
t
tall-airline-16756
02/16/2026, 9:24 AMThanks for reaching out, Piyush. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
tall-airline-16756
02/16/2026, 9:24 AMHi — thanks for reaching out!
How can I help you today? A couple quick prompts to get us started:
• Are you setting up LiveKit for a project or troubleshooting an existing room/connection?
• If troubleshooting, can you share the project ID, room ID, and a brief description of the issue (error messages, browser/OS, steps to reproduce)?
Whichever you prefer, tell me a bit more and I’ll guide you through the next steps.
t
tall-businessperson-30911
02/16/2026, 9:24 AMI’m currently working on a LiveKit-based real-time audio communication app that is live and published on the Google Play Store as part of a community project. We’re facing persistent audio distortion issues that are impacting call quality in production.
We’ve reviewed the documentation and tried basic troubleshooting, but the issue still persists. We would really appreciate guidance on identifying the root cause.
t
tall-airline-16756
02/16/2026, 9:25 AMThanks — I hear you: audio distortion in production is urgent and frustrating, and you want help finding the root cause. I can guide you through focused diagnostics and likely fixes, but I need a few key details to narrow down causes quickly.
Below are targeted questions and quick checks that will help us isolate whether this is audio processing, codec/network, device hardware, or routing related. Please reply with as many answers as you can.
1) Where and when the distortion happens
• Does the distortion occur on the sender, the receiver, or both?
• Does it start immediately when a call connects, or after some time (e.g., after network changes, after joining multiple participants)?
• Is it reproducible for all users or only some (specific geographic regions, carriers, Wi‑Fi vs cellular)?
2) Devices, OS, and app build
• Which Android devices and OS versions are mostly affected?
• Are affected users on the Play Store build or an internal/test build? If both, are versions identical?
• Any patterns by headset vs speakerphone, Bluetooth vs wired?
3) Audio pipeline and SDK settings
• Are you using any audio processing features (for example, OS-level processing, LiveKit agent noise cancellation like `BVC()`/`BVCTelephony()`, or third‑party filters)?
• Have you set
bypassVoiceProcessingbypassVoiceProcessingBVC()BVCTelephony()t
tall-businessperson-30911
02/16/2026, 9:42 AM1.) distortion happens on the sender and receiver, both sides
it starts after joining multiple participants
I am not sure about reproducing it but it happens when multiple participants joins at the same time (and by multiple participants I mean 6 to 7 users)
2.) I have an android and it happens in locally testing and production app both
There is no pattern
4.) small groups - 7 to 10 users when joined
rest I am not sure what it has or what problems
t
tall-airline-16756
02/16/2026, 9:43 AMThanks — this is helpful. I hear that distortion appears on both sender and receiver, and it reliably shows up when many participants (around 6–7) join at roughly the same time in small group calls. That points us toward issues that appear under load: audio mixing/CPU constraints, client-side audio processing contention, codec/bitrate changes, or network/packet handling when concurrent joins occur.
Next steps — focused tests and information that will quickly narrow the root cause Please run these tests and send back results/logs you can capture. Each test targets a specific potential cause so we can isolate the layer that’s failing.
1) Reproduce with a minimal controlled test
• Create a 1–1 baseline test (two devices, same network) and confirm audio is clean.
• Then reproduce the 7-user scenario on the same network and note when distortion begins (immediate vs after simultaneous joins).
Why: confirms whether the problem only appears under concurrent join load.
2) Check CPU / memory and thread contention on sender devices
• While reproducing, monitor the Android device CPU and memory (Android Studio Profiler or simple adb) on devices that are joining. Note any CPU spikes or main-thread stalls when the 6th–7th user joins.
Why: multiple local encoders + mixing + noise cancellation can saturate CPU and introduce distortion on both send & receive.
3) Test bypassing device processing
• Toggle
bypassVoiceProcessingbypassVoiceProcessingt
tall-businessperson-30911
02/16/2026, 9:46 AMport: 7880
room:
departure_timeout: 5
auto_create: true
empty_timeout: 5
max_participants: 50
rtc:
tcp_port: 7881
port_range_start: 40000
port_range_end: 50000
use_external_ip: true
node_ip: 34.131.236.43
packet_buffer_size: 1000
packet_buffer_size_audio: 1000
congestion_control:
enabled: true
pli_throttle:
low_quality: 500ms
mid_quality: 1s
high_quality: 1s
keys:
xxxxx:xxxxxx
turn:
enabled: true
domain: livekit.aardosolutions.com
cert_file: /etc/letsencrypt/live/livekit.aardosolutions.com-0001/fullchain.pem
key_file: /etc/letsencrypt/live/livekit.aardosolutions.com-0001/privkey.pem
tls_port: 5349
udp_port: 3478
relay_range_start: 50001
relay_range_end: 60000
external_tls: true
webhook:
api_key: lk_dev_key
urls:
- https://token.aardosolutions.com/livekit/webhook
logging:
level: info
t
tall-airline-16756
02/16/2026, 9:46 AMThanks — this is very helpful. I can see your server-side LiveKit config (ports, TURN, congestion control, packet buffer sizes, PLI throttles). You’ve confirmed distortion appears on both sender and receiver when ~6–7 participants join at roughly the same time. That strongly suggests the issue happens under concurrent join/load and could be caused by one or more of: client CPU/mixing/processing saturation, encoder bitrate/reconfiguration, SFU buffering/congestion handling, or transient network/packet loss.
Next I’ll give a prioritized diagnostic plan you can run (server- and client-focused), what to collect, and a few immediate mitigations to try now.
What to test next (priority order) 1) Reproduce with logging and connection stats
• Cause targeted: network/SFU vs client.
• Action: Reproduce the 6–7 simultaneous join scenario while collecting SDK connection stats on every client. Capture these at 1–2s intervals for the period around the join spike: uplink/downlink bitrate, packetLoss, jitter, rtt, encoder bitrate, and audio track send/recv state.
• What to look for: sudden packet loss or bitrate drops at the same time distortion starts; large jitter spikes; repeated reconnections.
2) Capture local vs received audio samples
• Cause targeted: sender audio vs network/SFU/receiver processing.
• Action: On one sender, record local raw audio (before publishing). On one receiver, record the received audio. Compare: if local is clean but received is distorted, problem is SFU/network/receiver processing. If local is distorted, problem is sender device or local processing.
• Format: short 10–30s clips around the incident.
3) Monitor device CPU and thread load during joins
• Cause targeted: client-side CPU / mixing / processing overload.
• Action: Use Android Studio Profiler or adb dumpsys to sample CPU usage, thread count, and main-thread stalls on clients joining. Note spikes when the 6th–7th participant joins.
• What to look for: CPU saturation, GC spikes, long main-thread blocking. If present, audio artifacts often follow.
4) Try bypassing device processing and simplifying pipeline
• Cause targeted: conflicting audio processing (multiple cancellation stages).
• Action: Temporarily enable
bypassVoiceProcessingpacket_buffer_size_audio: 1000bypassVoiceProcessingt
tall-businessperson-30911
02/16/2026, 9:52 AMFuture<void> setMicEnabled(bool enabled) async {
if (_room == null) return;
final trackPub =
_room!.localParticipant?.audioTrackPublications.firstOrNull;
final track = trackPub?.track;
if (enabled) {
// UNMUTE
if (track != null) {
await track.unmute();
} else {
// Fallback: If track missing, publish it
debugPrint('⚠️ [LiveKitEngine] Track missing, republishing...');
await _room!.localParticipant?.setMicrophoneEnabled(true);
}
} else {
// MUTE
if (track != null) {
await track.mute();
}
// DO NOT unpublish (setMicrophoneEnabled(false)) to avoid negotiation delay
}
_isMicEnabled = enabled;
notifyListeners();
}
// ------------------------------------------------------------------
// DEAFEN (subscribe/unsubscribe remote audio)
// ------------------------------------------------------------------
void setDeafened(bool deafened) {
_isDeafened = deafened;
_updateDeafenState();
notifyListeners();
}
void _updateDeafenState() {
if (_room == null) return;
final shouldHear = !_isDeafened;
for (var p in _room!.remoteParticipants.values) {
for (var pub in p.audioTrackPublications) {
if (shouldHear) {
if (!pub.subscribed) pub.subscribe();
} else {
if (pub.subscribed) pub.unsubscribe();
}
}
}
}
// ------------------------------------------------------------------
// METADATA (Sync state to others)
// ------------------------------------------------------------------
Future<void> updateMetadata(Map<String, dynamic> metadata) async {
if (_room == null || _room!.localParticipant == null) return;
try {
final jsonStr = jsonEncode(metadata);
_room!.localParticipant!.setMetadata(jsonStr);
} catch (e) {
debugPrint('⚠️ [LiveKitEngine] Failed to update metadata: $e');
}
}
// ------------------------------------------------------------------
// PRIVATE — AudioSession Configuration
// ------------------------------------------------------------------
Future<void> _configureAudioSession() async {
try {
final session = await AudioSession.instance;
await session.configure(
AudioSessionConfiguration(
avAudioSessionCategory: AVAudioSessionCategory.playAndRecord,
avAudioSessionCategoryOptions:
AVAudioSessionCategoryOptions.allowBluetooth |
AVAudioSessionCategoryOptions.allowBluetoothA2dp |
AVAudioSessionCategoryOptions.defaultToSpeaker,
avAudioSessionMode: AVAudioSessionMode.voiceChat,
avAudioSessionRouteSharingPolicy:
AVAudioSessionRouteSharingPolicy.defaultPolicy,
avAudioSessionSetActiveOptions: AVAudioSessionSetActiveOptions.none,
androidAudioAttributes: AndroidAudioAttributes(
contentType: AndroidAudioContentType.speech,
usage: AndroidAudioUsage.voiceCommunication,
),
androidAudioFocusGainType: AndroidAudioFocusGainType.gain,
androidWillPauseWhenDucked: false,
),
);
} catch (e) {
debugPrint('⚠️ [LiveKitEngine] AudioSession config failed: $e');
}
}
// ------------------------------------------------------------------
// PRIVATE — Room Event Listeners
// ------------------------------------------------------------------
Timer? _notifyDebounceTimer;
void _debounceNotify() {
if (_notifyDebounceTimer?.isActive ?? false) return;
_notifyDebounceTimer = Timer(const Duration(milliseconds: 500), () {
notifyListeners();
});
}
void _setupListeners() {
_listener!
..on<RoomConnectedEvent>((_) {
notifyListeners();
})
..on<RoomDisconnectedEvent>((event) {
// Notify MeetingController — it decides whether to reconnect.
_status = ServiceStatus.disconnected;
notifyListeners();
onUnexpectedDisconnect?.call();
})
..on<ParticipantConnectedEvent>((_) {
if (_room == null) return;
_participants = _room!.remoteParticipants.values.toList();
_debounceNotify();
})
..on<ParticipantDisconnectedEvent>((_) {
if (_room == null) return;
_participants = _room!.remoteParticipants.values.toList();
_debounceNotify();
})
..on<LocalTrackPublishedEvent>((_) {
_isMicEnabled = _room?.localParticipant?.isMicrophoneEnabled() ?? false;
notifyListeners();
})
..on<LocalTrackUnpublishedEvent>((_) {
_isMicEnabled = _room?.localParticipant?.isMicrophoneEnabled() ?? false;
notifyListeners();
})
..on<TrackMutedEvent>((e) {
if (e.participant == _room?.localParticipant) {
_isMicEnabled = false;
notifyListeners();
} else {
_debounceNotify();
}
})
..on<TrackUnmutedEvent>((e) {
if (e.participant == _room?.localParticipant) {
_isMicEnabled = true;
notifyListeners();
} else {
_debounceNotify();
}
})
..on<TrackSubscribedEvent>((e) {
_updateDeafenState();
_debounceNotify();
})
..on<ActiveSpeakersChangedEvent>((e) {
_debounceNotify();
})
..on<RoomReconnectingEvent>((_) {
debugPrint('⚠️ [LiveKitEngine] Reconnecting...');
_status = ServiceStatus.connecting;
notifyListeners();
onReconnecting?.call();
})
..on<RoomReconnectedEvent>((_) {
debugPrint('✅ [LiveKitEngine] Reconnected');
_status = ServiceStatus.connected;
notifyListeners();
onReconnected?.call();
})
..on<ParticipantConnectionQualityUpdatedEvent>((e) {
if (e.connectionQuality == ConnectionQuality.poor) {
debugPrint(
'⚠️ [LiveKitEngine] Poor connection: ${e.participant.identity}',
);
}
})
..on<RoomEvent>((e) {
// 🟢 Fallback for any metadata event (ParticipantMetadataChangedEvent, etc.)
if (e.runtimeType.toString().contains('Metadata')) {
notifyListeners();
}
});
}
t
tall-airline-16756
02/16/2026, 9:52 AMThanks — this is very helpful. I’ve reviewed your server config and your client code. You’ve shown that distortion appears for both senders and receivers when ~6–7 participants join at once, and your code shows how you publish/unpublish, deafen, and configure audio session. That context strongly points to a load-related problem (client CPU/mixing, encoder reconfig, SFU buffering or transient packet loss) but I still need a few targeted pieces of info and logs to pinpoint the root cause.
Summary of likely causes given what you’ve shared
• Client-side CPU / audio processing overload when many publishers appear simultaneously (encoding + noise cancellation + mixing).
• Conflicting or heavy audio processing chains on devices (system + app + any AI/agent models).
• SFU/server transient congestion or buffer churn when many tracks publish at once.
• Encoder bitrate reconfiguration or packet loss during the simultaneous-join burst.
What I need next (please provide as many as you can)
• LiveKit Android SDK version and the client library version you’re using.
• One or two example affected Android device models and OS versions (e.g., Pixel 5 / Android 12).
• Whether you use any LiveKit Agent noise-cancellation models or other third‑party audio processing in the app.
• Whether you set
bypassVoiceProcessingbypassVoiceProcessing = truefalset
tall-businessperson-30911
02/16/2026, 9:52 AMFuture<void> connect(String wsUrl, String token) async {
if (_status == ServiceStatus.connecting ||
_status == ServiceStatus.connected) {
return;
}
_status = ServiceStatus.connecting;
_errorMsg = '';
notifyListeners();
try {
final roomOptions = RoomOptions(
adaptiveStream: false,
dynacast: false,
defaultAudioPublishOptions: const AudioPublishOptions(
name: 'audio',
dtx: true,
red: true,
encoding: AudioEncoding(maxBitrate: 48000),
),
defaultAudioCaptureOptions: const AudioCaptureOptions(
stopAudioCaptureOnMute: false,
noiseSuppression: false,
echoCancellation: true,
autoGainControl: true,
),
defaultVideoPublishOptions: const VideoPublishOptions(simulcast: false),
);
_room = Room(roomOptions: roomOptions);
_listener = _room!.createListener();
_setupListeners();
// Configure AudioSession ONCE — voiceCommunication mode.
// This is the ONLY AudioSession.configure() call in the entire app.
await _configureAudioSession();
await _room!
.connect(
wsUrl,
token,
connectOptions: const ConnectOptions(
autoSubscribe: true,
timeouts: Timeouts(
connection: Duration(seconds: 15),
debounce: Duration(seconds: 2),
publish: Duration(seconds: 10),
subscribe: Duration(seconds: 15),
peerConnection: Duration(seconds: 20),
iceRestart: Duration(seconds: 20),
),
),
fastConnectOptions: FastConnectOptions(
microphone: const TrackOption<bool, LocalAudioTrack>(
enabled: true, // 🟢 Publish immediately
),
),
)
.timeout(
const Duration(seconds: 20),
onTimeout: () {
throw TimeoutException('WebSocket Connection Timeout');
},
);
// 🟢 Mute immediately after connect (Soft Mute)
final trackPub =
_room!.localParticipant?.audioTrackPublications.firstOrNull;
if (trackPub != null && trackPub.track != null) {
await trackPub.track!.mute();
} else {
// Fallback: Ensure published but muted
await _room!.localParticipant?.setMicrophoneEnabled(true);
await _room!.localParticipant?.audioTrackPublications.firstOrNull?.track
?.mute();
}
_isMicEnabled = false;
_isDeafened = false;
_participants = _room!.remoteParticipants.values.toList();
_status = ServiceStatus.connected;
notifyListeners();
debugPrint(
'✅ [LiveKitEngine] Room connected. Participants: ${_participants.length}',
);
} catch (e) {
_status = ServiceStatus.error;
_errorMsg = _classifyError(e);
notifyListeners();
rethrow;
}
}
t
tall-airline-16756
02/16/2026, 9:53 AMThanks — this is great detail. I see your Room connect code and audio publish defaults (no dynacast/adaptive, audio encoding maxBitrate 48kbps, DTX/RED enabled, echo cancellation and auto gain on, noiseSuppression false). That helps narrow things down.
Key observations from your config and code
• You publish audio immediately on connect (fastConnect microphone enabled) and then mute — this avoids negotiation delays but still creates an immediate publish load when many users join simultaneously.
•
adaptiveStreamdynacastsimulcastnoiseSuppressionechoCancellationautoGainControldefaultAudioCaptureOptions.noiseSuppression = truebypassVoiceProcessing = trueechoCancellationautoGainControlAudioEncoding(maxBitrate: 24000)maxBitratebypassVoiceProcessingt
tall-businessperson-30911
02/16/2026, 10:08 AMso basically I have a android device running on android 16, livekit_client: ^2.6.2
flutter_webrtc: 1.3.0 # Compatible with livekit_client
I dont use use any LiveKit Agents or other server-side audio processing / AI noise cancellation.
not using any
bypassVoiceProcessingt
tall-airline-16756
02/16/2026, 10:09 AMThanks — this is very helpful. I can see your environment (Android 16, livekit_client 2.6.2, flutter_webrtc 1.3.0), you’re not using Agents or server-side AI processing, and your server logs show many join attempts plus errors like “room has exceeded its max participants” during the stress test. You also publish immediately on connect (fastConnect) and then mute, so many clients are starting audio encoders and publishing simultaneously.
Given everything you’ve shared, the issue is most likely a burst-load problem: either client-side CPU/audio-processing overload when many publishers start at once, or transient SFU/network congestion/buffering during the simultaneous publish spike. Below I’ll give a short prioritized checklist of the next tests to run, immediate mitigations you can apply, and exactly what logs/metrics to collect so I can pinpoint the root cause.
Prioritized tests (do these in order) 1) Stagger publishes (quick verification)
• Change fastConnect/publish so each client delays publishing the microphone by 300–700 ms after connect (or add a small randomized delay when many users join).
• Reproduce the 6–7 user simultaneous-join test.
• Why: If distortion disappears or reduces, the cause is burst-load (client CPU or SFU burst handling).
2) Local vs received audio capture (definitive isolation)
• On a sender, record a short local raw microphone clip (before sending).
• On a receiver, record the corresponding received audio.
• Compare: if local is clean but received is distorted → SFU/network/receiver processing; if local is distorted → sender/device processing or encoder issue.
3) Client CPU / thread & GC profiling during reproduce
• On one affected Android device, run Android Studio Profiler or capture
adbAudioEncoding(maxBitrate: 24000)echoCancellationautoGainControldefaultAudioCaptureOptionsechoCancellationautoGainControl3 Views