Re: Initial draft of mediacapture-output spec posted

Thanks Justin.  Could you push the changes to the gh-pages branch so it
shows up on the github.io live preview?  (In the web audio specs, we
actually deleted the master branch altogether and only use the gh-pages one
to simplify this.

As Philippe intimates, there are a number of supported device capabilities
and constraints we'll want to hook into; for example, asking a given audio
device what sampleRates it supports.  It's likely that's a range, but with
particular values; we'll also want supported number of channels.  It seems
like we can't get that on enumeration today, but maybe I'm just not reading
the right bit of the spec.

On Wed, Dec 17, 2014 at 11:00 AM, 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 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.
>
> 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>
> 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, 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> wrote:
>>
>> View it at: https://w3c.github.io/mediacapture-output/
>> File issues, submit changes at:
>> https://github.com/w3c/mediacapture-output/
>>
>>
>>