RE: [mediacapture-main] Allow device capabilities to be discoverable via enumerateDevices (#211)

Hmmm.  A couple of thoughts:

The spec does have some significant symmetry and consistency issues.  It seems well-adapted to support conferencing solutions – allowing selection of one or more input devices (mic, camera) with constraints, and giving _implicit_ support for access to an associated output device.  But not, as you noted in your comment, for more general web audio solutions, where output devices are as important (if not more) than input devices.

There is no matching call to getUserMedia() for output devices – it’s not needed, since there is implicit permission granted – if the user allows use of a mic with a headset, the user agent can assume they’re OK with using the headset’s speakers.  From an architectural point of view, this feels like a partial solution to the general problem of audio input and output, and it feels like the solution does not horribly complicate the specification.

The spec is fairly far down the road, but this feels like a real missed opportunity for either our WG or the Device/WebRTC WGs to properly consider the full set of use cases related to both input and output of media.  As a W3C process newbie – do others have suggestions about the right approach here?

-Bill


From: Joe Berkovitz [mailto:joe@noteflight.com]
Sent: Thursday, August 06, 2015 9:58 AM
To: Audio Working Group
Subject: Fwd: [mediacapture-main] Allow device capabilities to be discoverable via enumerateDevices (#211)

FYI -- output device characterization is not looking so good for inclusion in the final Media Capture spec, though input devices look likely to be covered by my earlier proposal, with some modification. This may have to wait for the Audio Output API to take shape, unless others have better ideas than I on how to proceed.

Please see the github PR for more details:

https://github.com/w3c/mediacapture-main/pull/211#issuecomment-128408222<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_mediacapture-2Dmain_pull_211-23issuecomment-2D128408222&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=KROTG3x0KqACk7aI9V7SPoO3BSAvPNPX8k2eg-sGUyw&s=12YiGsqeUAeKV0V8ml4qb0q2YsTAAaRbRtZ4FCXdtLc&e=>

---------- Forwarded message ----------
From: jan-ivar <notifications@github.com<mailto:notifications@github.com>>
Date: Thu, Aug 6, 2015 at 10:18 AM
Subject: Re: [mediacapture-main] Allow device capabilities to be discoverable via enumerateDevices (#211)
To: w3c/mediacapture-main <mediacapture-main@noreply.github.com<mailto:mediacapture-main@noreply.github.com>>
Cc: Joe Berkovitz <joe@noteflight.com<mailto:joe@noteflight.com>>


@burnburn<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_burnburn&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=KROTG3x0KqACk7aI9V7SPoO3BSAvPNPX8k2eg-sGUyw&s=C63OsLLhfK5stesyliELqhk-wiPeJHhL5ovQ-XKT9Qs&e=> thanks for explaining the reason for the exception.

Having an Audio Output spec add this makes sense to me FWIW. It might be worth pondering whether such a spec would be likely to extend (with the partial webidl keyword) either MediaTrackCapabilities or MediaDeviceInfo. If the latter, we may want to rename info.capabilities to info.inputCapabilities now to anticipate this (assuming we're still going ahead). *

*) Because (MediaTrackCapabilities or OutputCapabilities) capabilities wont work, as two dictionaries are not distinguishable<https://urldefense.proofpoint.com/v2/url?u=https-3A__heycam.github.io_webidl_-23dfn-2Ddistinguishable&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=KROTG3x0KqACk7aI9V7SPoO3BSAvPNPX8k2eg-sGUyw&s=YXJUFa1LoQ5Xit8KoZvb0JMbS2_2oDbtQmF-ozwZKQU&e=> from each other in webidl today.

—
Reply to this email directly or view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_mediacapture-2Dmain_pull_211-23issuecomment-2D128408222&d=AwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=qzKCNHFKJMzZBJ52at1DkA-_8TPxvcij-zS_VXs8c5A&m=KROTG3x0KqACk7aI9V7SPoO3BSAvPNPX8k2eg-sGUyw&s=12YiGsqeUAeKV0V8ml4qb0q2YsTAAaRbRtZ4FCXdtLc&e=>.