W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2015

Audio WG requests

From: Joe Berkovitz <joe@noteflight.com>
Date: Tue, 26 May 2015 14:21:05 -0400
Message-ID: <CA+ojG-b1QsDS1UUJQAump7jLfRDVMMMHdAXt85Dr5ovXwXawBg@mail.gmail.com>
To: Stefan HÃ¥kansson <stefan.lk.hakansson@ericsson.com>, Harald Tveit Alvestrand <harald@alvestrand.no>
Cc: Audio Working Group <public-audio@w3.org>, public-media-capture@w3.org
Hello Chairs,

Other than the minutes from the most recent call, I haven't seen much
additional group feedback on the enumerateDevices() question since last
week, so I think this is a good time to propose a specific direction that
is hopefully feasible for the Task Force.

Here are our points in priority order:

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.

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.

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.

Please let us know how we can best work with you and the task force to
resolve a joint direction on these points.

Thank you!

Best,
-- 
.            .       .    .  . ...Joe

*Joe Berkovitz*
President

*Noteflight LLC*
49R Day Street / Somerville, MA 02144 / USA
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"
Received on Tuesday, 26 May 2015 18:21:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:33 UTC