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](https://jsfiddle.net/jib1/k9s3acLf/). 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, 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.
Bug 1688981 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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](https://jsfiddle.net/jib1/k9s3acLf/). 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.