Re: Audio WG requests

On Wed, May 27, 2015 at 6:36 AM, Joe Berkovitz <joe@noteflight.com> wrote:
> 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().

getUserMedia is effectively for getting the microphone (and the
camera), so asking for mono/stereo makes some sense.

However, it has nothing to do with the choice of speaker vs headphones
- that should be related to the audio output api.

Incidentally, I have a big need to choose the output device in my app
- people want notifications (such as an incoming call) to be generally
heard, even when the headphones are plugged in - just in case they had
put the headphones down.

Cheers,
Silvia.

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

Received on Tuesday, 26 May 2015 21:29:56 UTC