Re: Audio WG requests

Hi Harald,

Thank you for your patient and informative response. I am glad that my
reading of the minutes of the call was not warranted -- I appreciate your
clarification.

I also now see that my mistaken focus on getUserMedia() obscured the fact
that the Audio Output API doesn't provide a way to select an output device
using the Constrainable pattern. So we have an open question about how the
API can initially request access to a device that is, at least, a likely
choice for output, in order to enable the return of further and more
complete information. getUserMedia() with constraints serves this purpose
for input; there is no analogue for output.

So we are inching forward -- at least in terms of improving my
understanding of the picture. Is there a next step that you think can help
move these issues forward?

Best,
...Joe

On Wed, May 27, 2015 at 2:30 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

>  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
>  "Your music, everywhere"
>
>
>
> --
> Surveillance is pervasive. Go Dark.
>
>


-- 
.            .       .    .  . ...Joe

*Joe Berkovitz*
President

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