search

w3c / mediacapture-output

API to manage the rendering of audio on any audio output device
https://w3c.github.io/mediacapture-output/
Other
26 stars 25 forks source link

Predefined IDs conflict with future direction of device selection #51

Closed joeberkovitz closed 7 years ago

joeberkovitz commented 7 years ago

I am concerned that the use of predefined IDs with somewhat vague meanings (see https://cdn.rawgit.com/w3c/mediacapture-output/master/index.html#mediadeviceid-enum) sets up a recipe for confusion that will not be easy to get rid of in the future. While these appear to map to some existing MS Windows concepts, that does not provide applications with the ability to offer a meaningful choice of output device to end users (imagine offering users the choice of "playback" or "communications" in a music synthesizer app, for example). I suggest that these IDs be omitted from the spec altogether at this stage.

My belief is that most developers need to be able to discover devices that satisfy various context-dependent constraints, e.g. "is a headphone", "is a speaker", "can support 44K sample rate", "can support a 5.1 channel layout". I am aware that this work is being deferred to a later phase of enhancing enumerateDevices(), and so on. But I think that's the best place to focus effort on selecting devices, rather than on a stopgap distinction between playback and communications.

alvestrand commented 7 years ago

This seems like an argument that is interesting in the context of #19 . Can we merge those issues?