Re: DeviceID - reserved values, how to express? (#173)

I agree that predefined device IDs are not the way to go. They are much
more limited in expressivity than the constraints approach that the MC API
has adopted for getUserMedia(). Notions such as "is a communications
device" can be handled as constrainable properties.

Overall, audio output device discovery, access, enumeration and privacy
should be handled in a way that is congruent with audio input, i.e. makes
use of constraints, and uses identical interfaces for device capabilities
wherever possible.

...Joe

On Fri, Jun 12, 2015 at 1:34 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

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


-- 
.            .       .    .  . ...Joe

*Joe Berkovitz*
President

*Noteflight LLC*
49R Day Street / Somerville, MA 02144 / USA
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"