1688981 - WebRTC - Disconnecting Airpods does not reroute microphone

Status: RESOLVED INVALID

(Core :: WebRTC: Audio/Video, defect, P3)

Description

[topherauyeung]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.80 Safari/537.36

Steps to reproduce:

1. Open one (or both) of the following webRTC test pages in Firefox with Airpods connected: https://webrtc.github.io/test-pages/src/single-audio/ or https://webrtc.github.io/test-pages/src/audio-and-video/
2. Remove your Airpods and put them back in their case, effectively disconnecting that audio source

Actual results:

1. Video freezes
2. Audio output ceases entirely

Expected results:

1. Video should not freeze
2. Audio output should reroute to the native computer speakers (this is what happens in Chrome, if you want to see expected behavior)

Comment 1

[Nico Grunbaum [:ng, @chew:mozilla.org]]

topherauyeung, thanks for your bug report!

Jan-Ivar, were you investigating something like this recently?

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

1. Video freezes
2. Audio output ceases entirely

This symptom is because audio input (Airpod microphone) is dropped, not output. That's why the video freezes. Update: video freezes before they're put in the case. Tracked separately in bug 1689741.

Comment 3

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

This appears to be a bug in Chrome. Concerning for web compat indeed.

To appreciate what's going on, open https://webrtc.github.io/samples/src/content/devices/input-output — In Chrome and Edge I see:

Audio input source: ✓ Default: Jan-Ivar Bruaroey's AirPods (Bluetooth) ▼
                      MacBook Pro Microphone (Built-in) 
                      Jan-Ivar Bruaroey's AirPods

In Firefox and Safari I see:

Audio input source: ✓ AirPods                ▼
                      MacBook Pro Microphone

Chrome and Edge default to a virtual "Default: ..." microphone that appears to (somewhat) track macOS's dynamic default — Firefox removed this duplicate "Default" microphone 3 years ago in bug 1404977.

I say "somewhat" because when I test this in Chrome, I notice:

1. Once capture from "Default: ..." has started, Chrome switches dynamically only when AirPods turn off, not on.
2. Track labels exposed to the page never update, which can be seen here.
3. I experienced some serious non-recovering audio distortion a couple of times doing this.

When this was standardized years ago, web developers said they wanted full control over cameras and microphones, which unfortunately conflicts with browsers making smart decisions behind their back.

As a result, according to the spec, things like headset detection is up to sites to implement: https://jsfiddle.net/jib1/yohgar95/ — This works better with Firefox's permission model, which is per-device by default. Thus Firefox wouldn't always be able to implicitly auto-switch like Chrome did here.

And last, but not least, this auto-behavior in Chrome is limited to users of the "Default: ..." device. Try picking any other device in the first link in this comment, and the auto-behavior won't kick in, which means sites need to write all that JS I wrote in the last link anyway. Except because of Chrome, they're less likely to discover that they need to.

Comment 4

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

I've filed this as https://crbug.com/1172033

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #2)

1. Video freezes
2. Audio output ceases entirely

This symptom is because audio input (Airpod microphone) is dropped, not output. That's why the video freezes.

After discussing with pehrsons, we agree the video should not freeze. I've filed bug 1689741 on that. Everything else said remains true.

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Tip: to avoid video freezing (bug 1689741) while reproing this, turn off Automatic Ear Detection. 🙂

Comment 7

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Closing this as I believe this works as intended, and to spec. Chrome is working on their issue in comment 4.

Again, the video freeze is covered over in bug 1689741.