Audio Output Devices API

[foolip]

https://w3c.github.io/mediacapture-output/

There is an Intent to Ship this API on blink-dev, so if possible please prioritize this review.

[torgo]

taken up 11-11 on telecon

[torgo]

Alex: We need @travisleithead on this...

[torgo]

@slightlyoff to write up thoughts here and hopefully we can come up with some conclusions quickly

[foolip]

If you feel like you have the domain expertise, it would be nice to hear some thoughts about the potential for different shapes of the API for HTMLMediaElement and the Web Audio API, which I asked some questions about on blink-dev:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/ELz4SxMwa0U/CWsWMGjfCwAJ

The situation we find ourselves in is that we don't have the primitives that underly both Web Audio and media elements, and this is the cause of some uncertainly both for this API and Media Session.

[alvestrand]

Hope to hear from you next week, then?
We're code complete on the implementation, TAG review is one of the things that people have asked for before we ship the feature.

[travisleithead]

I've looked this over today.

Audio Output Devices API

Reviewed: https://w3c.github.io/mediacapture-output/ (25 November 2015)

My takeaway: The design and concepts are simple and integrate well with other Web RTC concepts (e.g., the enumerateDevices() API). While I don't really like the name (sinkId; more below), otherwise, the integration points are fine. I note (as also noted above), that we don't yet have a fundamental concept of an audio/multimedia engine that would provide the substrate for features like this, though to be fair, this feature is only related to such an engine on the output edge (not tied to primitive operations--though it does describe starting/stopping audio).

Specific feedback:

• sinkId is only for Audio? The name seems a bit ambiguous when applied to HTMLMediaElement (audio + video). In the context of a video element, sinkId could be confusing.
• id-communications -- is the issue resolved with how to deal with headsets?
• id-communications - what happens when this value is assigned, yet no comm device is available? The processing model needs to include specifics on handling these special values.

[alvestrand]

The sink-ID seems to work OK in practice, given that there isn't yet a model I know of where a page can choose which screen to display an element of.

I'm not sure what the writer of the NOTE for the headset issue intended to say, so can't answer that.
I think the right answer for the other question is that if the underlying system doesn't support "id-communications", it should default to the default device ("" or "id-multimedia").
I'll file a bug to that effect.

[torgo]

Discussed at TAG teleconf 16 December 2015: https://github.com/w3ctag/meetings/blob/gh-pages/2015/telcons/12-16-agenda.md

Summary of discussion: Good Consensus around Travis's comments, but should also hook into permissions API.

[travisleithead]

@alvestrand, additionally, the spec does not appear to hook into the Permission API (should file an issue to add a permission enum into that spec). That way it can keep track of permissions related to audio output.

[torgo]

Agreed to close on teleconf 16-dec. Will re-open if further requests come in.

[slightlyoff]

As an aside, it's be great to see example code for this API somewhere so that folks can get a sense for how it hangs together with the rest of the system. The attribute/promise split for getter/setter might make a ton of sense, but it's hard to see. Same for the pre-defined devices list.

[alvestrand]

WebRTC / permissions API interaction is currently the subject of another ongoing discussion, so I think we are aligned here.

Example code can be found here: https://webrtc.github.io/samples/src/content/devices/multi/