- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 05 Jan 2021 08:11:30 +0000
- To: public-webrtc-logs@w3.org
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. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-output/issues/116#issuecomment-754478397 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 5 January 2021 08:11:31 UTC