Re: Initial draft of mediacapture-output spec posted

I've updated gh-pages. PTAL at http://w3c.github.io/mediacapture-output/,
which has the latest updates.

On Thu, Dec 18, 2014 at 1:46 PM, Chris Wilson <cwilso@google.com> wrote:

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