Repository navigation
Add 'Mic Stop On Mute' checkbox to change behavior of handsfree mode for bluetooth headsets - #6447
Merged
Merged
Conversation
Hecklezz
reviewed
Oct 14, 2026
| "-framework CoreMedia" | ||
| "-framework CoreVideo" | ||
| "-framework Foundation" | ||
| "-framework Security" |
Contributor
There was a problem hiding this comment.
Mixed tab and space indenting making it not line up
Hecklezz
reviewed
Oct 14, 2026
Comment on lines
+248
to
+250
| // Ignore webrtc.lib's InitRecording (sent when a send stream starts), as | ||
| // with StartRecording/StopRecording: it would leave capture initialised even | ||
| // while we hold capture off. The app initialises capture itself via ForceInitRecording. |
Contributor
There was a problem hiding this comment.
Comments need indenting (I fixed it right after you pulled the changes into this branch :) )
…sequences we were calling workerStartRecording when unmuting when configured to go out of hands free mode on bluetooth devices when muting. telling libwebrtc to change devices might be a bit overkill and have unintended consequences. Also, fixed some formatting.
akleshchev
approved these changes
Oct 15, 2026
roxanneskelly
marked this pull request as draft
October 15, 2026 18:53
Contributor
Author
|
Back to draft as we need some product and design decisions as to what the default is, and on the copy. |
… (Better in-world audio)
akleshchev
approved these changes
Oct 21, 2026
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
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.
Description
Bluetooth drops it's bandwidth and goes mono when the microphone is enabled. It's just an artifact of the bluetooth technology, and there's nothing that can be done about it. In secondlife, this results in poor audio quality when listening if voice is enabled, as the viewer activates the microphone to prepare for input while voice is enabled.
In 26.2, we only activated the microphone when mute was toggled. This results in a 'hiss' when you start speaking, and can result in a disruptive delay and audio artifact when toggling the mute button. The only thing that can be done about that is to keep the microphone active (but not listening) at all times, which is what we did in 26.3.
Unfortunately, this results in poor quality (lower bitrate, mono) when listening to other sources like DJs, music from mp3s, etc.
The fix is to give users a choice as to whether they want to favor voice behavior, or other audio like music.
Issue Link: #6433
Test Guidance:
See #6433
Kudos to @Hecklezz for this work.