tree ae09bedb9aa8e842a62161b96da0b93f6cb42760
parent 6b521c5909b7d21926990fefe972c16398dae9a8
author John Grossman <johngro@google.com> 1510092239 -0800
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> 1510098274 +0000

[usb][audio] Fix a bug, improve volume hack.

Fix an issue where we were attempting to set the sample rate of an
interface which only supported a single sample rate, which cause the
device to stall the interface's endpoint.  Now, if an interface
supports only one sample rate, we do not attempt to set it to anything
in particular.

Also, add some functionality to the set_volume hack.  Volume in USB
audio was more complicated than the previous hack was expecting.
Volume controls (if they exist) will exist in the 'Feature' unit (if
it exists) in the great big bucket of audio units which make up the
audio path.  The feature unit has a bitmask which indicates which
control exist for every channel which has features.  There tends to be
at least one channel (index 0, the 'master' channel), and sometimes
more channels (one for each speaker, indexed [1, N]).  There are at
least 10 different controls in the feature unit descriptor for each
channel including volume and mute.  Attempting to either set or query
a control which does not exist for a given channel is supposed to
cause the device to stall the endpoint (which some devices do and some
devices don't).

So, with this CL, we now pay attention to the feature unit descriptor
when attempting to set the initial volume, and we don't attempt to
touch controls which are not supposed to exist.  When setting the
volume, we attempt to set the volume and mute controls for each
channel in the feature unit based on support.

Finally, there was a bug in the commands being issued when setting
volumes which has been fixed.  Specifically, there are 4 numbers which
make up the address of a control in a feature unit.  They are the...

1) Interface ID
2) Feature Unit ID
3) Control Selector
4) Channel Number

Each is 1 byte long.  1 and 2 are supposed to be combined and sent as
the wIndex field of the control request, while 3 and 4 are supposed to
be combined and sent as the wValue field of the request.  Prior to
this change, 1 was being combined with 3, not with 2 as it should be.

Change-Id: If36839d86a6eb3b5f8c26287019c92eb8726a3e1