Audio Control | Default to using earpiece when doing audio vs speaker for video call (depending on presence of headset or not)#3801
Open
BillCarsonFr wants to merge 5 commits intolivekitfrom
Open
Conversation
a8dcebf to
d2856dd
Compare
290e53c to
83b343c
Compare
9da0a5c to
d3a12d5
Compare
Add comments on existing code Extracted a specific android controller for isolation and better testing lint fixes Fix device update logic and more tests better typescript
36b7648 to
9c2b2d4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Content
fix #3774
This PR is a following up the recent addition of voice call support on android.
When you accept a voice call on android, EC was automatically choosing the speaker audio routing instead of earpiece. Speaker is a good default for video calls, but for voice call you expect the sound out of the earpiece.
We do not handle routing the same way for every platfrom. Mobile has some specificities, as well as some limitations when using only the web API.
That's why we have some native/custom controls for mobiles.
There are been severl iterations, testing, tweaks for the mobile integration. Part of the code is a bit messy due to that (deprecated code, attributes, outdated behavior, etc..)
I spent some time adding more documentation and logs.
We have more than a difference between mobile and web, there are notable difference between iOS and android.
That's why I decided to extract a specific android audio control class AndroidControlledAudioOutput.
It allows me to do extensive testing with real life android values, without riskign regressing any iOS behavior.
The
AndroidControlledAudioOutputnow uses the initial call intent to decide for the best default.It is also responsible for auto-swtiching to a device if a new device is added or removed.
If a new device is added it will only switch to it if it is more private. e.g:
Notable change: The android native part used to also do some automatic switching, this was causing selection flickers, as there was 2 different things trying to set a good default.
This is not the case anymore, EC has all the informations to decide for the best device. So the
AndroidControlledAudioOutputdoesn't listen to native calling the controls to set a device.=> Need a follow-up task on android, to do some clean-up:
Screenshots / GIFs
Tests
Checklist