PING review

[pes10k]

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.

1. 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?

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

3. 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!

[youennf]

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:

• If the deviceId is present, selectAudioOutput resolves without a prompt and exposes the device to enumerateDevices
• If the deviceId is not present, selectAudioOutput will show a prompt so that the user can select the audio output to use.

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:

1. Step 7 of setSinkId will reject if deviceId is not exposed by enumerateDevices. The algorithm already covers the case of the note. The note tries to explain the model. Do you have ideas on how to improve the description of the model?
2. and 3. Once a deviceId is exposed by enumerateDevices (be it from selectAudioOutput or getUserMedia prompt), there is no difference of behavior or treatment. In both cases, setSinkId will resolve and implementor should use the device for audio output.

[alvestrand]

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.

[pes10k]

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?

1. 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?

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

[youennf]

1. If deviceId is not already exposed in enumerateDevices, setSinkId will reject, even if the deviceId is actually corresponding to a valid audiooutput device. You are correct that "if enumerateDevices() is giving information about audiooutput devices, then you can bypass selectAudioOutput() for those devices". That said, enumerateDevices() will expose only a subset of all audiooutput devices, contrary to what is done for capture devices after a successful getUserMedia call. "if has given access to the specific deviceId before on this page, you can bypass selectAudioOutput()" is generally wrong.
2. If you manage to guess a deviceId, you need to pass it through selectAudioOutput before using it. At that point, it is up to the User Agent to either silently accept it or show a prompt. The idea here is that applications that might want to guess deviceIds for tracking purposes will not do it given the risk of showing a prompt.