Re: Accepting Audio WG proposals

>
> Also, the second should not be cast as track capabilities, they are device
> capabilities.
>
Hi Martin,

I agree, the intent here is to provide device capabilities and I would
welcome your concrete suggestions on how to improve the proposals.

What exactly would it mean, to cast the second proposal as "device
capabilities"? It seems to me that you may be raising more than one
question about device capabilities, which I'll attempt to deal with
separately.

First, are track-level capabilities a meaningful facet of a device's
capabilities? I think they are, because devices' streams contain tracks.
The "kind" attribute of MediaDeviceInfo constrains the type of each device
to audio or video (the choice being audioinput/audiooutput/videoinput), and
according to the definition of getUserMedia() there can only be one
MediaTrack of any given type (audio or video) in the collection of tracks
for any returned MediaStream for some device. So it seems that a single
MediaTrackCapabilities should take care of describing the capabilities of
the sole relevant track contained in any device described by a
MediaDeviceInfo, and MediaTrackCapabilities is already defined and agreed.

The second question is whether there is a need for some higher-level
MediaDeviceCapabilities structure that describes
non-track-related-capabilities. At the moment, it appears that there are no
device-level data structures in the API other than MediaStream and
MediaDeviceInfo. Neither appears to contain any capabilities-type
information. So I could not see the need at present. Was this what you were
recommending, that such a structure be defined? If so, would it include the
MediaTrackCapabilities describing the device's tracks?

...Joe