Open Bug 1660002 Opened 4 years ago Updated 4 years ago

Consider muting 1st mic on opening 2nd (to improve mic-switching web compat in Firefox)

Categories

(Core :: WebRTC: Audio/Video, enhancement)

enhancement

Tracking

()

People

(Reporter: jib, Unassigned)

References

Details

The current getUserMedia API requires sites to handle hardware (and browser) limitations by checking for NotReadable errors and make appropriate fallbacks, like stopping existing devices before picking a new one.

In hindsight, this was perhaps too much to put on sites, so this idea from D86072 sounds appealing:

Loose thought on stopgap measure for solving the mic-switch use case: when 2nd mic is requested, mute (implied: turn off) the 1st. The most common case of requesting a 2nd live mic is a settings dialog to switch away from the 1st. This way we'd avoid the wait time from gUM request to prompt-approval that apps otherwise have to do.

We could unmute the 1st when the 2nd is stopped.

What would we do if it turns out to be a genuine 2nd mic request and not a switch?

Live with a muted 1st mic. Is that worse than rejecting the 2nd? Mic-switching seems like a much more common use-case so I'd argue no.

Hmm, is this moot now with achronop's cross-graph work for setSinkId? I'll figure this out in the coming weeks.

You need to log in before you can comment on or make changes to this bug.