b) I assume you are using the Platform audio path but can you please confirm?
Now to your problems:
For Platform audio, I sometimes noticed the same behaviour you see in #1. and #2. I have a fix probably similar to yours calling into Android APIs, but mine is reordering the priorities to Bluetooth > Speaker > Earpice. So it should solve your issues #1 and #2 at the same time. Have a look at the Android specific code here:
For your issue #3 I can not really say anything myself as I don’t have a Samsung phone on me. But to narrow down the issue, you could compare against using the Unity audio route and also compare against using the standard Meet sample.
Thanks for the update. I tested the latest changes using the Meet Sample and wanted to share my feedback.
For this test, I added PlatformAudioController.cs exactly as provided in the GitHub repository and updated MeetManager.cs to match the latest GitHub version. Here are the results:
Headset routing: Audio is now routed correctly to a wired headset or Bluetooth headset if it is already connected before joining the room. However, if I connect or switch to a headset after joining, the playback audio does not switch to the headset.
Fallback after disconnecting a headset: If I join the room with a headset connected, playback works correctly through the headset. However, after disconnecting it, the playback falls back to the earpiece speaker instead of the device’s media/loud speaker.
Samsung microphone issue: The low microphone volume issue still exists. I’m not yet certain whether this is specific to Samsung devices, but so far I’ve tested on 4 Samsung devices, and all of them had the same very low microphone volume problem. I also tested on 2 non-Samsung devices, and they did not have this issue. I tested both the Unity Audio implementation and the Meet Sample (PlatformAudio), and both exhibited the same barely audible microphone volume on the affected Samsung devices.
Additional observation: On the affected Samsung devices, if I use a wired or Bluetooth headset for the call, the low microphone volume issue disappears. The problem only occurs when using the phone’s built-in microphone.
Please let me know if there is any additional logging or information I can provide to help investigate these remaining issues.
@Alireza_Karimy, Max’s PR #364 handles #1 and #2, so the open one is #3. Quick map:
#1/#2: Platform Audio routes playback through the native WebRTC ADM, which defaults to the earpiece on Android. PR #364 reorders it to Bluetooth > Speaker > Earpiece. Pull that in and both should resolve.
#3 cause: Platform Audio applies auto gain control and hardware processing on the mic capture, the README lists it as unlocking “echo cancellation, noise suppression, auto gain control.” That AGC is the mic-level knob, and on some Samsung units it clamps the captured level hard, which fits your symptom exactly: quiet transmitted audio while your own playback is fine.
No SDK knob today: the audio session is hardcoded (the iOS side is tracked in #330); there is no exposed Android audio-mode or source setting.
The quick diagnostic and workaround is to publish the mic through the Unity Audio path instead, which does not run that native AGC/processing:
var micObject = new GameObject("my-audio-source");
var rtcSource = new MicrophoneSource(Microphone.devices[0], micObject);
var track = LocalAudioTrack.CreateAudioTrack("mic", rtcSource, room);
var options = new TrackPublishOptions { Source = TrackSource.SourceMicrophone };
yield return room.LocalParticipant.PublishTrack(track, options);
rtcSource.Start();
If the Samsung level jumps back, the native AGC was it. Realistic trade-off: Unity Audio drops the hardware echo cancellation Platform Audio gave you, so on an open loudspeaker you may need software AEC or push-to-talk. If you want to stay on Platform Audio and still fix the gain, a focused issue with the exact Samsung models is the route.
Regarding #1 and #2, I’ve already posted my test results after trying Max’s PR, so I’m waiting for Max’s response.
Regarding your suggestion for diagnosing #3, I actually started with the Unity Audio path before Platform Audio was introduced. I implemented microphone publishing using MicrophoneSource, as you suggested, and the low microphone volume issue was still present on the affected Samsung devices. So unfortunately, the problem doesn’t seem to be specific to Platform Audio or its AGC.
At this point, it seems more likely that the issue is either device-specific or somewhere deeper in the Android/Unity/WebRTC audio stack.
Quick check on the Samsung issue, are you also playing out Unity audio, for example some ambient music? This could be an indicator if the Unity app in general is restricted in volume or if it is just the LiveKit audio.
Another data point would be if you could join the room with another front end than Unity and check if the volume is already low on the wire or if the error is in the Android or Unity playout. On Android, we offer the native Android SDK, the Flutter SDK or the React Native as well to build apps. They should all have a meet like example which you can point to your project id and room id to join. That way you can also see if it is Unity, Android or LiveKit specific issue. You can also run use the Browser Meet sample, this is what I do: GitHub - livekit-examples/meet: Open source video conferencing app built on LiveKit Components, LiveKit Cloud, and Next.js. · GitHub.
One important clarification regarding the Unity audio: we actually exported and tested the Meet Sample itself in Unity, completely separately from our game. So the tests I mentioned were not performed only inside our billiards game.
The Meet Sample also reproduced the same low microphone volume issue on the affected Samsung devices.
In our game, the only additional audio is the sound effects from the billiards gameplay, such as ball collisions. We also tested the voice chat while doing nothing in the game and only talking, and the result was exactly the same.
Also, Unity audio and the voice chat are using separate Android volume streams. Unity/game audio is played through the media volume, while the voice chat is played through the call volume, and their volumes can be adjusted independently.
So I don’t think the game’s audio or the general Unity playback volume is contributing to the issue.
The only other things that come to my mind right now is to either go back to Unity audio and try to manipulate the output volume through post processing. I drafted the work here for you and it works for me: Audio boost script by MaxHeimbrock · Pull Request #367 · livekit/client-sdk-unity · GitHub. A second Audio Filter is multiplying the volume with a factor.
Is that a viable intermediate solution for you? Other than that can you name the Samsung devices so I can see if I can get my hands on one of them?
I also wanted to follow up on the other two issues I mentioned in my previous feedback, separate from the low volume microphone issue.
Regarding #1 and #2, I tested the latest changes using the Meet Sample with PlatformAudioController.cs and the updated MeetManager.cs from the GitHub version.
The results were:
If the headset is already connected before joining the room, playback is routed correctly through the headset.
However, if I connect a headset after already joining the room, the playback does not switch to the headset.
If I join with a headset connected and then disconnect it during the call, playback falls back to the earpiece speaker instead of the device’s media/loud speaker.
You mentioned that Max’s PR #364 handles #1 and #2 by changing the playback routing order to Bluetooth → Speaker → Earpiece.
Could you confirm whether these two behaviors are expected to be fixed by PR #364, or if they require additional changes for handling audio-device changes while a room is already active?
I’m currently waiting for confirmation on these two points before doing further testing.
Yes, I think this solution is good enough as an intermediate step for me to test it and give you feedback on the results. I’ll test the implementation from PR #367 on the affected Samsung devices.
However, I don’t think simply multiplying the audio volume can be the final solution. At the moment, I don’t have a reliable way to determine which devices are affected by this issue. So I wouldn’t know when the volume needs to be boosted and when it doesn’t, and applying a fixed multiplier to all devices could result in unnecessarily high volume on devices that don’t have the problem.
I agree that manually tuning the volume like this is not a solution you want to put in the final product. Thanks for sharing the Samsung models you experience the issues with and I see what I can do.
Sorry for not responding to the other issues you raised when the audio device changes at runtime. My PR is not able to fix the issues you mention I believe. Handling the switching of audio devices might still be error prone and I have this on my list to address in a bigger investigation, I just haven’t found the time. I assume this is a blocker for you right now?
Yes, the runtime audio-device switching issue is a blocker for us right now.
The reason is that we don’t currently have an option for the user to leave and rejoin the voice room. So if the user joins without a headset and then connects one during the room, the audio doesn’t switch to the headset. The same happens in reverse when they disconnect the headset and the playback falls back to the earpiece.
Also, this voice chat is a VIP feature in our game, so having a reliable audio experience is particularly important for us.
As a temporary workaround, my current idea is to add a “Troubleshoot Audio” button. When the user taps it, we would disconnect and reconnect them to the voice room, which should reinitialize the audio routing.
This would only be a temporary workaround until the runtime audio-device switching issue is properly fixed. If you have any better suggestion for handling this without reconnecting the user to the room, I’d be happy to try it.