Re: Initial draft of mediacapture-output spec posted

I’ve provided my recommendation for the explicit consent in the github issue: https://github.com/w3c/mediacapture-output/issues/2 <https://github.com/w3c/mediacapture-output/issues/2>. Let’s take it from there.

Thanks - Philippe

> On Dec 17, 2014, at 9:00 PM, Justin Uberti <juberti@google.com> wrote:
> 
> The problem with consent is that it's not clear how to clearly indicate this to the user. 
> 
> "example.com <http://example.com/> wants to enumerate your output devices" is not something that most users will understand, so the implicit authorization mechanism is likely what most applications will use. 
> 
> We can figure out the details of explicit consent in https://github.com/w3c/mediacapture-output/issues/2 <https://github.com/w3c/mediacapture-output/issues/2>.
> 
> BTW, I updated the document to add the AudioContext ctor option proposed by Chris.
> 
> On Wed, Dec 17, 2014 at 1:25 AM, Philippe Joseph Cohen <philc@audyx.com <mailto:philc@audyx.com>> wrote:
> Thanks Justin for this update. This is a great step forward. I have few questions:
> 
> 
> In section 4.2 you wrote that:
> The user agent may explicitly obtain user consent to play audio out of non-default output devices; the details of this process are left to the implementation.
> 
> I wonder it should not be better to require such consent so to write should rather than may. This is mostly because I believe the user consent will impact the enumerateDevices method of the NavigatorUserMedia in order to set the MediaDeviceInfo.label. In plain english, if in order for an app to use the right deviceId (sinkId) in an AudioContext the app should know something about the device (based on the label info for example).
> 
> Furthermore, shall we not add to the MediaDeviceInfo type fields such as sampleRate and numberOfChannels (for distinguishing stereo from 5.1, ...) as defined in http://webaudio.github.io/web-audio-api/#idl-def-AudioBuffer <http://webaudio.github.io/web-audio-api/#idl-def-AudioBuffer>, based on user consent, so the application will really know which device to use.
> 
> Last I agree with Chris I guess with most/all the WebAudio API folk that an AudioContext constructor with the sinkId is the best solution, since an AudioContext cannot really change its output device easily especially if they do not have the same sample rate, so it’s good to have the Web Audio API specialists such as Chris involved. Having additional audio information field in the MediaDeviceInfo will greatly help the app to use the right sinkId in the AudioContext ctor.
> 
> Best regards - Philippe 
> 
> 
> 
> 
>> On Dec 17, 2014, at 12:49 AM, Justin Uberti <juberti@google.com <mailto:juberti@google.com>> wrote:
>> 
>> View it at: https://w3c.github.io/mediacapture-output/ <https://w3c.github.io/mediacapture-output/>
>> File issues, submit changes at: https://github.com/w3c/mediacapture-output/ <https://github.com/w3c/mediacapture-output/>