Re: Filtering of enumerateDevices() results

Ahh yes, as you say, that would be perfect. 

.            .       .    .  . ...Joe

Joe Berkovitz
President
Noteflight LLC
+1 978 314 6271
www.noteflight.com
"Your music, everywhere."

> On May 20, 2015, at 2:11 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> Den 20. mai 2015 18:00, skrev Joe Berkovitz:
>> 
>>> 1. For audio devices, channel count and a binaural (essentially,
>>> speaker-vs-headphone) flag are important attributes.
>> 
>>    Query - are these distinct attributes or points on the same continuum?
>> 
>>    ie will a monaural device always have channel count 1? Or is the
>>    "binaural" flag specifically for the headphone case, with "each ear of
>>    the listener hears one and only one channel"?
>> 
>> 
>> These are distinct attributes.  "Binaural" means the device delivers a
>> signal to each ear of the listener separately, as in headphones.
>> 
>> Although it seems this might be restricted to the 2-channel case,
>> perhaps it's better not to legislate that. The species might evolve :-)
>> 
>>> 2. How would the WG feel about including more "filtered" information in
>>> the MediaDeviceInfos returned by enumerateDevices(), other than the
>>> device label -- information that the application can use to restrict or
>>> augment the list of devices displayed to a user (since constraints are
>>> not accepted by enumerateDevices())? Ideally channel count, binaural,
>>> sample rate and other attributes such as width and height could be
>>> exposed here.
>> 
>>    Query - do you think of these things as singular attributes or as a
>>    range of possible values? IE some devices are capable of being
>>    configured into multiple sample rates - what info would you want?
>> 
>> 
>> Hmmm, I hadn't considered. If the information is returned in each
>> MediaDeviceInfo object then perhaps a range would be necessary. In which
>> case the approach of submitting constraints to enumerateDevices() (to be
>> ignored if filtering is in effect) might be superior.
>> 
>> 
>>    Also - what do you think of when you say "width" and "height" here? Are
>>    you thinking of video sources, or is there something new here?
>> 
>> 
>> I was thinking of video sources.
>> 
>> 
>> 
>>    If we don't care about fingerprinting, exposing the result of calling
>>    getCapabilities() on a device might be OK. Or not....
>> 
>> 
>> I think that may not  work for this purpose because one would have to
>> call getUserMedia() for every device in the enumerated list... with lots
>> of permission grant interactions with the user.
> 
> I was thinking in terms of returning in the result of enumerateDevices()
> data structures for each device containing what would have been the
> result if you called getCapabilities() on a track connected to that
> device. Fingerprints can't get much better than that.
> 
> 
>> 
>> .            .       .    .  . ...Joe
> 
>