Re: Audio WG requests

>
> I think that I can conceive of a use case, but your request wasn't
> clear. Let me try to repeat what I think you are asking for.
>
> You want to specify constraints that apply not to the input device
> that will produce the resulting media, but to the *associated* output
> device.  I imagine that the idea is to ensure a compatible *pair* of
> devices in the case where output is routed to a paired device.
>
> If that's the case, I'll let the chairs decide how to proceed.  This
> reads as a new feature request to me.  It's good to have the input,
> but we have this strange process where we decide to stop accepting
> changes.
>

I would like once more to ask the chairs' help to help us resolve this need
for identifying audio input and output devices that satisfy applications'
channel count and/or binaural-output constraints.

It is true that the emphasis for us is primarily on output devices,
although input devices matter too. The Audio Output API is not sufficient
to resolve this problem alone, as it lacks a constraints mechanism for
resolving output devices based on constraints. It does have a predefined
device ID for "system communications" that may or may not reliably identify
a headset, depending on one's reading of the spec.

I'd also like to respond to your comment about "this strange process where
[the task force] decides to stop accepting changes". We've been in a
dialogue since TPAC in October with the MCTF chairs about the need to
identify the sinkIds of output devices satisfying some basic constraints
such as channel count, etc.  Our Last Call comments were also noted in
https://www.w3.org/2006/02/lc-comments-tracker/47318/WD-mediacapture-streams-20150414/
so I do not believe we are late to the party. We're just persistent, since
our needs haven't been addressed yet. Perhaps we framed them in a
less-than-savvy way in terms of the current API, but I think our needs are
clear.

Having said that, please excuse the clumsiness of the proposal as I
presented it. You're correct that getUserMedia() is currently limited to
identifying input devices, and as such may not be the best way to achieve
our aim of identifying an *output* device satisfying channel count and/or
headphone criteria. Perhaps enumerateDevices() is a better vehicle -- it
could take constraints also (in a non-filtered scenario where the user
granted access to a device). But the only response to our request in
today's call minutes seemed to dismiss any attempt to get
enumerateDevices() to return more information, even in situations where the
TF has already agreed to return fingerprint-sensitive information such as
device labels. I did not follow that reasoning, and one of the chairs had
already responded favorably to that idea in a note on which this group was
copied.

One more point -- this is not about pairing compatible input and output
devices. Audio applications can generate output with no processing of input
devices. So we have a need to identify output devices that are compatible
with the application's characteristics (not necessarily some intput
device's characteristics). If an app produces stereo output, it would like
to identify an output deviceId that supports stereo.

I hope we can find a way to move forward here.

-- 
.            .       .    .  . ...Joe

*Joe Berkovitz*
President

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