search

w3c / audio-session

https://w3c.github.io/audio-session/
Other
1 stars 2 forks source link

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

Open youennf opened 1 year ago

youennf commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

youennf commented 1 month ago

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 commented 1 month ago

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).