In case an AudioSession is explicitly set, should some incompatible APIs start failing?

[youennf]

If a web page sets an explicit audio session to ambient, a call to getUserMedia({audio:true}) can only succeed if the active audio session is set to play-and-record.
Either we need to change the audio session type, or we need to activate a different audio session, or we need to have getUserMedia fail.

[jernoble]

a call to getUserMedia({audio:true}) can only succeed if the active audio session is set to play-and-record.

Or, "auto", which is the default.

The only way to get into this situation is to explicitly set the default audioSession.type away from "auto" or "play-and-record", which seems to be a minor foot-gun. Maybe this can be solved with a different Exception code returned from getUserMedia()?

[youennf]

The additional question is when the type is changed during capture.
Should capture fail or not in that case?

[youennf]

As mentioned by @eric-carlson, the other case is having an active gum, and trying to set audioSession.type.
The alternatives would be to throw or to fail capture.

[youennf]

Tentative TPAC 2024 proposal: reject gum in case of conflicting audioSession.type, and fail capture if audioSession.type is set (as retrying to capture would reject).