Bug 282939 – getUserMedia({audio: true}) does not return system selected device

• Component: Web Audio
• Status: NEW

When calling getUserMedia({audio: true}), I would expect the track that gets returned to belong to the currently selected audio device. Instead, it appears to _almost_ always return the built-in Microphone.  A simple test is to connect AirPods or wired headphones and run the following in the console:

getAudio = () => {
  navigator.mediaDevices.getUserMedia({audio: true}).then(
    (stream) => {
      deviceId = stream.getAudioTracks()[0].getSettings().deviceId;
      navigator.mediaDevices.enumerateDevices().then(
        (dev) => {
          chosenDevice = dev.filter((d)=>d.deviceId === deviceId);
          console.log(`Selected Device: ${chosenDevice[0].label}`);
        }
      )
      stream.getTracks().forEach((t)=>t.stop())
    }
  )
};
getAudio();

The result will log 'iPhone Microphone'.

What makes this worse is that making this call also switches the output device, so all audio for the page switches to the iPhone speaker.

I have reproduced this on iOS 17.6.1 and 18.1. I'm still investigating to hopefully provide more helpful information and code snippets but wanted to submit this quickly to get eyes on it.

Created attachment 473195 [details]
getUserMedia() test #1

I am attaching three basic html pages the use getUserMedia() to grab audio and demonstrate the issue.

The first simply performs the `getAudio()` I had in my original comment on a 5 second loop, reports what device was used and then discards the tracks and stream. In general, I find that it mostly returns the 'iPhone Microphone', but can occasionally get it to temporarily pick up my Air Pods if I switch between tabs. Subsequent getUserMedia() calls typically end up back on the iPhone Mic, though, so it's short-lived.

The second snippet steps through playing an audio file before calling `getUserMedia({audio: true})`, demonstrating how the audio will initially play from the headphones, but will switch to the iPhone speakers once `getUserMedia()` is called. It has some other toggles for testing like manually switching devices and adding the microphone track to an audio element to hear it played back.

The third snippet is almost identical to the first except instead of immediately stopping the tracks and throwing away the stream, it keeps the stream around and stops the tracks 2 seconds later.  With this test, I was once able to get getUserMedia() to get into a state where it would inconsistently switch back and forth between the built-in mic and the AirPods. It doesn't happen always so I'm a bit baffled how/when/why it can get into that state (which still isn't ideal), but thought it worth including.

Created attachment 473196 [details]
getUserMedia() test #2

Created attachment 473197 [details]
getUserMedia() test #3

[Radar WebKit Bug Importer]

<rdar://problem/140129366>

[Andrew Petersen]

I have encountered the same exact behavior. I'd like to also add that if you use a wired headset+mic, sometimes the iphone mic will still be used even though output is routed through the headphones! Very confusing.

I found a workaround for all scenarios though:

- set `navigator.audioSession.type = 'auto'` (just to reset to defaults)
- call `getUserMedia({audio: true})`, this will return the iphone mic and likely reroute audio output to the handset speakers
- set `navigator.audioSession.type = 'play-and-record'`

This seems to "kick" iOS into rerouting audio. Now the external device's mic and speakers (headphones) will be used!

Sometimes, an additional problem will manifest after you have closed the mic stream/tracks: the audioSession will remain in `play-and-record`, resulting in degraded audio output quality. The solution is to:

- set `navigator.audioSession.type = 'playback'`
- set `navigator.audioSession.type = 'auto'` (immediately, no need for a delay)

This will again "kick" iOS into rerouting / resetting audio. You'll be back in hi fidelity!

I hope this helps!