RE: Initial draft of mediacapture-output spec posted

Speaking for myself here, I can see a wide range of use cases where an app would benefit from knowing (given the right permissions) some basic characteristics of an output device:


·         Channel count and configuration (Mono, Stereo, 5.1, 7.1, 5.1.2, 7.1,4, etc…)

·         Physical Output (Headphone, Speaker, HDMI, SPDIF, Bluetooth, Miracast, …)

·         Latency (this matters a lot for gaming, and also in other use cases)

·         Output capabilities (bitstream passthrough vs PCM)

It is perhaps sufficient from a user interface point of view to have a string to display, but for a program to be able to either adapt to the user selection or to guide the user selection, these are pretty important characteristics.  Many if not most of the host OSes that user agents run on expose these sorts of output device characteristics.

-Bill

From: Chris Wilson [mailto:cwilso@google.com]
Sent: Thursday, December 18, 2014 1:47 PM
To: Justin Uberti
Cc: Philippe Joseph Cohen; public-media-capture@w3.org
Subject: 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__github.io&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=w2VToUYQcUH99Sz5WImu3d78akzc-swwsTGhLCrpQG4&s=USyM46rspfEc5cQt7c6nz0Bh687Ghm_F42XAcn4SeAg&e=> 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<mailto:juberti@google.com>> wrote:
The problem with consent is that it's not clear how to clearly indicate this to the user.

"example.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=w2VToUYQcUH99Sz5WImu3d78akzc-swwsTGhLCrpQG4&s=tSiiJRetL1iYqGFBgiYHS6oT8gmBjaq94fzQpoKuQHQ&e=> 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_mediacapture-2Doutput_issues_2&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=w2VToUYQcUH99Sz5WImu3d78akzc-swwsTGhLCrpQG4&s=iQujMzehfaZW3qC1h-era6HPfi8TmftrlFrfVrRlX9w&e=>.

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__webaudio.github.io_web-2Daudio-2Dapi_-23idl-2Ddef-2DAudioBuffer&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=w2VToUYQcUH99Sz5WImu3d78akzc-swwsTGhLCrpQG4&s=Jwhf6cB_J2yocj81kxB8urZjneLllZVqoGo8jAHuymc&e=>, 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://urldefense.proofpoint.com/v2/url?u=https-3A__w3c.github.io_mediacapture-2Doutput_&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=w2VToUYQcUH99Sz5WImu3d78akzc-swwsTGhLCrpQG4&s=aNVeef33HAT8A_ChKQFR3gFz2f-hWuD8JmU3J98Il0Q&e=>
File issues, submit changes at: https://github.com/w3c/mediacapture-output/<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_mediacapture-2Doutput_&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=w2VToUYQcUH99Sz5WImu3d78akzc-swwsTGhLCrpQG4&s=H4mbLccG6gSpJFV18Aj1hDaxw5xxEv9cx3iu2b6x_2M&e=>