- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 12 Jun 2015 10:34:38 -0700
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 12 June 2015 at 01:28, Harald Alvestrand <harald@alvestrand.no> wrote: > - Drop the idea of predefined DeviceIDs and ban it forevermore. After some consideration, I think that this is the right answer. We have to consider the use case that is raised by the audio output API before we can decide this. The use case audio output is addressing is a good one, one that I believe the main spec should handle. That is: sites just want a way to select the configured default. And there are different defaults sometimes. The model there basically assumes a pseudo-device that maps to each of these two defaults. That has some advantages: - you can actually have the browser change out a device seamlessly - you don't need new identification mechanisms - it is marginally more privacy-preserving because sites don't learn which device is default It also has some real disadvantages: - changing devices seamlessly isn't guaranteed to work - changing devices seamlessly isn't needed if the application watches for ondevicechange events - changing devices seamlessly might result in surprising outcomes, like resolution (or more likely) sample rate changes - even if we deal with this issue, the potential for confusion is greater On balance, I think that the right answer to this is to add a new constraint that is driven by a new enumeration: navigator.mediaDevices.getUserMedia({audio: {default: "communications"}}) We could also expose a new property on the enumerateDevices output to report what the browser understands about devices. We don't need to expose that always, since the set of values is well known; that eliminates the (trivial) privacy advantage of the alternative that audio output proposes. We need a rule for what to do with unknown or unsupported values here (map to "multimedia" might be sensible, or maybe we can define a new "system" value for the enum). That's an inherent shortcoming with the audio output proposal as it stands.
Received on Friday, 12 June 2015 17:35:07 UTC