Re: Audio WG requests

On 26 May 2015 at 11:21, Joe Berkovitz <joe@noteflight.com> wrote:
> 1) The Audio WG strongly suggests the inclusion of two new constraint
> attributes in the MediaTrackConstraints and MediaTrackCapabilities
> interfaces: a channel count, and a binaural (effectively,
> speaker-vs-headphone) flag. The WG feels these are the bare minimum needed
> to constrain and describe audio output devices in a meaningful way for
> audio-intensive applications.

How do you envisage using these constraints?  They can't be used with
getUserMedia.  And getUserMedia is the only user of constraints that
I'm aware of.

> 2) The Audio WG strongly wishes to support an AudioContext constructor that
> accepts a device ID argument as a sinkID, as outlined in the Audio Output
> API section 3.1.1
> (http://w3c.github.io/mediacapture-output/#constructor-argument). Ideally,
> the entire Audio Output API would be implemented, but if we can at least
> enshrine the ability to use a MediaDeviceInfo.deviceId as the sinkID, that
> is enough to allow meaningful output device selection in Web Audio.

Doesn't the Audio Output API already cover that?

> 3) Ideally, we would like to see enumerateDevices() able to return
> information describing the MediaTrackCapabilities of each track in each
> enumerated device ***if the requester has already been granted access to at
> least one device by the end user***. The minutes from yesterday included a
> reference to "the drive-by web" with respect to this issue. I hope that was
> not intended as a characterization of what the Audio WG has been asking for
> -- we are only looking for such information to be surfaced in the same case
> where the device's descriptive label would already be exposed by the Media
> Capture API. The MC API specifies that this information will be exposed as
> long as the user has accepted at least one device for output -- which is the
> same condition that we are proposing. So no more fingerprinting would be
> allowed under this proposal than under the current MC API spec.

Exposing additional information in this fashion would be great.  Does
this have to covered by this iteration of the Media Capture API?  Or
can you live with addition of the parameters later, either in a new
version or a new specification?  For instance, I'd argue that the
Audio Output API is a good place to describe new output-specific
attributes.

Received on Tuesday, 26 May 2015 18:48:41 UTC