Open pes10k opened 3 years ago
Thanks for the review @pes10k. The model is as follow: a. If enumerateDevices is exposing audiooutput devices, deviceId can be used by setSinkId. b. If the application knows of a deviceId used in the past but enumerateDevices is not exposing it, the application is expected to call selectAudioOutput with the corresponding deviceId. One potential implementation for b. is:
Case a. can happen if getUserMedia is called and reveals microphones and related speakers. Case b. can happen for deviceId previously revealed by selectAudioOutput or getUserMedia.
Related to your questions:
note - calling getUserMedia returns only tracks connected to input devices. The reference to the getUserMedia permission prompt in 4.2 only refers to the idea that after presenting the getUserMedia permission prompt, the list of deviceIds returned by enumerateDevices() can change.
Thanks @alvestrand and @youennf !
Thank you for the clarification. I didn't quite have the correct understanding on my first read then. I have a broader question about the motivation behind the current approach, but want to make sure I 100% understand it first. Can you let me know what would should happen in each of the following cases?
I setSinkId with the deviceId of a valid audiooutput device, but one that hasn't been exposed to the page yet (Im thinking about the future, improving the privacy of enumerateDevices() changes we discussed previously)? Im trying to tease apart whether its "if enumerateDevices() is giving information about audiooutput devices, then you can bypass selectAudioOutput()", or if its "if has given access to the specific deviceId before on this page, you can bypass selectAudioOutput()", or a third thing?
the flows described in b seem to rely on deviceIds not being guessable. What happens if I manage to guess a deviceId, but which I haven't gone through the enumerateDevices requirements to have it revealed (either current or the additional, future discussed ones)?
Hello! I've completed the PING HR review of the spec. I found out a few issues I wanted to discuss and see if I'm reading it wrong, or if there are areas for possible improvement. If any of these issues are not already dealt with else where, or the result of my misunderstanding, please let me know and i'll create separate issues.
There is a at the end of section 3 (starting with "Applications that wish to rely on user agents"), which, if i understand correctly, seems to be saying that if I'm going to use a deviceID I got from getUserMedia, i need to also pass it through selectAudioOutput. Is this correct (I'm not sure how "persisted device ids" is supposed to modify this). If I'm understanding this correctly, why this is a note, in instead of part of the algorithm? Specifically as part of step 7 here?
Related, what should an implementor do if setSinkId is called with a deviceId that would "would be provided by enumerateDevices()", but which didn't come from "the getUserMedia() permission prompt" (section 4.2)
Related, what should an implementor do if setSinkId is called with a deviceId that would "would be provided by enumerateDevices()", but which hasn't been passed through selectAudioOutput?
Thanks!