- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 31 Jan 2012 15:12:46 +0100
- To: Chris Rogers <crogers@google.com>
- Cc: Doug Schepers <schepers@w3.org>, public-audio@w3.org, Dom Hazael-Massieux <dom@w3.org>, Henrik Andreasson <henrika@google.com>
On Jan 30, 2012, at 21:24 , Chris Rogers wrote: > Yes, it would be good to have an introspection API to enumerate the available audio devices for both audio input and output. A built-in microphone would be one such device. Also commonly available is the line-in analog audio input on a laptop or desktop computer. And, of course, any externally connected multi-channel USB or Firewire audio devices. Some of these can present eight (or more) simultaneous audio input and output channels simultaneously. I see where you're coming from, but enumeration is a potential fingerprinting problem. If any arbitrary page can start listing all the audio inputs and outputs that you have, especially if it includes their capabilities (as I guess that would be useful for your needs) then it starts becoming very easy to fingerprint a given user. The current model that gUM uses is that 1) the JS requests access to a media stream (with options), 2) the user is presented with a choice of sources from which to select, 3) the selected source is returned as a stream. So essentially the enumeration happens in the user <-> UA space, and isn't accessible to script. If that's sufficient for your needs, then we're probably gold, if not then we need to figure out something that works for you. The Gamepad API has a different model to prevent enumeration: gamepad information becomes available whenever there's activity on the gamepad. But I suspect that won't translate well to audio. Either way, we can find solutions, we just need to have a better picture of your needs and balance those against the need for privacy. I also suspect that the current model can only return a single source at a time and that that is likely to be an issue for audio (it might be okay for the user to have to work with a dialog to select sources, but it's probably not okay for the user to have to do that eight times in a row to select eight sources...). I think that the API could be modified to accept a "multiple" flag (just like file inputs) and correspondingly return an array of streams. > It's important to not consider audio input in isolation, but also audio output capabilities when enumerating the devices. I'm not sure that I really understand this comment. Right now, gUM is pretty much input-only. I certainly see how selecting outputs can be useful, but I'm not sure that it fits very well into this model (but I could very well be missing something). Please note that in pointing out issues above I'm not in any way rejecting your use cases. I'm merely pointing out that there are problems to be overcome, and that understanding what you need exactly would be very helpful in doing so. -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 31 January 2012 14:13:12 UTC