- From: guest271314 via GitHub <sysbot+gh@w3.org>
- Date: Mon, 07 Sep 2020 17:10:50 +0000
- To: public-webrtc-logs@w3.org
> @hills to make sure I understand clearly your request: if permission to a device is granted, but opening that device fails for other reasons, then you argue that enumerateDevices()̀ permission should be granted? This already occurs in practice at Chromium, deliberately, ostensibly for the claim that PulseAudio selects a monitor device when no input device is found; see https://bugs.chromium.org/p/chromium/issues/detail?id=931749#c6, https://chromium.googlesource.com/chromium/src/+/4519c32f528e079f25cb2afc594ecf625f943782 > PulseAudio: Filter out unavailable inputs and refuse to open monitor inputs > > If there are no available inputs, PulseAudio will, for some reason, > select the monitor of the current default sink as the default source. > Chrome will only add a Default input to the device enumeration if > there is at least one valid input found. Currently, we also include > unavailable inputs in the device enumeration, which means Chrome will > show a Default device, which in that case would likely be a monitor > device, rather than a proper input. > > This CL stops this happening by not enumerating inputs that don't have > an available, active port. In case PulseAudio would _still_ pick a > monitor device as the default device, this CL also explicitly returns > invalid AudioParameters for monitor devices, and explicitly fails to > open them as inputs - to be on the safe side. > where if there are no available inputs am not sure what the user is expecting other than a monitor device to be captured in that case when no microphone is connected to the machine. Chromium simply refuses to recognize monitor devices, captures microphone. Of course, if the user has no input devices, or connection to the device fails, that commit does not change anything - the user still has no microphone connected to the device - so the rationale for the change is at best unclear. Relevant to this topic that change means `enumerateDevices()` still has permission in that case, though the actual device captured is not what is expected to be captured. Further, if a user, in kind, refuses to accept that monitor devices will not be captured, and creates workarounds to actually capture the monitor device, since Chromium implementation refuses to list monitor devices, `enumerateDevices()` currently reports the incorrect devices, and makes it impossible to identify the device that is actually being captured https://github.com/w3c/mediacapture-main/issues/693, which is perhaps an unintended consequence of refusing to capture certain devices at the implementation level, while users in the field still have the requirement to capture such devices. Capture of monitor devices throws an error when set to default at OS. `enumerateDevices()` still has permissions, even though device capture fails for a specific device. Users should not be limited by specification authors initial use case conceptions. Video conferencing is not now the sole use case for `getUserMedia()` or `getDisplayMedia()`. The technology advances at least every 18 months; users might have multiple USB, Bluetooth, or other devices connected to their machine - and are not expecting `getUserMedia()` to refuse to connect to a device simply because the initial idea for `getUserMedia()` is for developers to conference. Media creation and editing use cases are not limited to just input microphone. -- GitHub Notification of comment by guest271314 Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/709#issuecomment-688442105 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 7 September 2020 17:10:52 UTC