Re: Audio WG requests

On Tue, May 26, 2015 at 2:48 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

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

We're explicitly asking that these two constraints *can* be used with
getUserMedia().


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

Yes, it does -- that's why I suggested that implementing the Audio Output
API would be ideal. Perhaps that's already agreed, in which case this item
isn't going to generate much discussion,


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

We could live with this later, but note that it is not output-specific. All
audio devices would benefit from a description of channel count, for
instance.

...Joe



-- 
.            .       .    .  . ...Joe

*Joe Berkovitz*
President

*Noteflight LLC*
49R Day Street / Somerville, MA 02144 / USA
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"