- From: Karl Tomlinson via GitHub <sysbot+gh@w3.org>
- Date: Tue, 27 Aug 2024 03:32:01 +0000
- To: public-webrtc-logs@w3.org
> The actual problem is that when you have a per-device permission model there is no way to know if the first exposed device is the UA default. Yes, that is the problem tracked in this issue. Thank you for identifying the source of some of our differences here. Media Capture and Streams uses the term "system default device for kind", while Audio Output Devices API more often uses "user agent default device". The OS has a default output device, which might be configurable per application (depending on the OS) including for each browser / user agent (depending on the OS), so I have assumed that both specs mean the system default device for the user agent. That is what I intended to describe here. I don't feel a need to distinguish unless some user-agents would like to distinguish between different kinds of OS default output devices. > Why would using the empty string (which has different meanings in different contexts) as ID for the default device in enumerateDevices solve this problem and not "default"? Perhaps the answer might already be clearer now in light of the different problem, but I'll elaborate. IIUC Chrome's `MediaDeviceInfo` with `deviceId: "default"` serves these purposes. 1. The primary purpose is that client apps that present the list of devices from `enumerateDevices()` to the user for output device selection will provide the user with a means of selecting a virtual output device that will follow changes in the system default output device. 2. A client app that uses the first "audiooutput" device from `enumerateDevices()` happens to get this virtual device and so is using the default device, even though Chrome does not reorder physical devices when the user-agent default device changes. Chrome always adds the `MediaDeviceInfo` with `deviceId: "default"` *in addition* to the default physical device. User agents are free to construct whatever virtual devices they choose and make these available under any unique `deviceId`. The primary purpose of the `MediaDeviceInfo` with `deviceId: ""` proposed here (and used in Firefox) is different. It serves these purposes. 1. The primary purpose is that is a placeholder so that the first audiooutput device returned by `enumerateDevices()` corresponds to the default output device. It signals that information about the default audiooutput device cannot be exposed, in a similar way to the single audioinput device returned before information about audioinput devices can be exposed. 2. It happens to be backward compatible with client apps that assume that the first audiooutput device is the default device, unaware of this bug in the spec. Its `deviceId` is accepted by `setSinkId()` and sends audio output to the system default device. `selectAudioOutput()` should be used instead of constructing a chooser from `enumerateDevices()` because `enumerateDevices()` does not necessarily list all available devices, but some clients are constructing their own choosers. The `MediaDeviceInfo` with `deviceId: ""` would be *in place* of the physical default device. There would be no such `MediaDeviceInfo` with `deviceId: ""` if the system default device is exposed. > IIUC now, the problem here is specific to a per-device permission model. In that case, I wouldn't be opposed to a field indicating if an entry is UA default. An additional attribute might be a possible solution, but it is quite a different mechanism to the current first-is-default mechanism. I proposed the placeholder device for similarity with the placeholder empty audioinput device and for its backward compatibility with client apps that assume the first-is-default mechanism. The placeholder would make an additional attribute unnecessary. > The way Chrome solves that problem right now is by setting the groupId to the same groupId of the physical device currently considered the default. A user agent is somewhat free to choose the `groupId` of a virtual device and "Two devices have the same group identifier if they belong to the same physical device." FWIW Chrome is inconsistent on this. I have heard reported the behavior you describe on MacOS, but the Linux behavior that I have seen is that the virtual default device has a different `groupId` to its current physical device. For a placeholder device, I feel an empty `groupId` would be more consistent with the signal that information about the default audiooutput device cannot be exposed. -- GitHub Notification of comment by karlt Please view or discuss this issue at https://github.com/w3c/mediacapture-output/issues/133#issuecomment-2311500326 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 27 August 2024 03:32:02 UTC