| commit | d363b58a8bb71379022d760d752e05a6e93892c8 | [log] [tgz] |
|---|---|---|
| author | John Grossman <johngro@google.com> | Tue Nov 07 14:03:59 2017 -0800 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Tue Nov 07 23:44:34 2017 +0000 |
| tree | ae09bedb9aa8e842a62161b96da0b93f6cb42760 | |
| parent | 6b521c5909b7d21926990fefe972c16398dae9a8 [diff] |
[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
Zircon is the core platform that powers the Fuchsia OS. Zircon is composed of a microkernel (source in kernel/...) as well as a small set of userspace services, drivers, and libraries (source in system/...) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation.
The canonical Zircon Git repository is located at: https://fuchsia.googlesource.com/zircon
A read-only mirror of the code is present at: https://github.com/fuchsia-mirror/zircon
The Zircon Kernel provides syscalls to manage processes, threads, virtual memory, inter-process communication, waiting on object state changes, and locking (via futexes).
Currently there are some temporary syscalls that have been used for early bringup work, which will be going away in the future as the long term syscall API/ABI surface is finalized. The expectation is that there will be about 100 syscalls.
Zircon syscalls are generally non-blocking. The wait_one, wait_many port_wait and thread sleep being the notable exceptions.
This page is a non-comprehensive index of the zircon documentation.