- From: Joe Berkovitz <joe@noteflight.com>
- Date: Tue, 26 May 2015 14:21:05 -0400
- 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
- Message-ID: <CA+ojG-b1QsDS1UUJQAump7jLfRDVMMMHdAXt85Dr5ovXwXawBg@mail.gmail.com>
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