Re: Audio WG requests

On 05/27/2015 02:59 AM, Joe Berkovitz wrote:
>
>     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 certainly a request for functionality that the current spec does
not address.
Nothing unusual about that.

>     It's good to have the input,
>     but we have this strange process where we decide to stop accepting
>     changes.
>

(note to Martin: We have this strange process where we publish
documents. This process leads to us having a period of time where we
want to push new features to other specifications, or mark them "to be
addressed later", so that we can actually improve the document's quality
to an acceptable state. In my opinion, that is a feature, not a bug;
YMMV. However, that discussion is something that won't be solved in WEBRTC.)

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

Indeed, I find this interaction to be exactly how the process for
resolving inter-group dependencies and needs is intended to work.

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

I did not read the call in this way - I read the call as being positive
to returning more information, acknowledging that the information would
be useful in the non-authorized case, and acknowledging that this is an
issue. My notes said "More work needed".

Your note saying that you'd be happy to see a solution (at least at this
juncture) that returns information only when you have access to a device
is very helpful.

>
> 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 <http://www.noteflight.com>
> "Your music, everywhere"


-- 
Surveillance is pervasive. Go Dark.