On Mon, Apr 11, 2011 at 12:34:23PM -0700, Stephen Warren wrote:
In ChromeOS, user-space attempts to manipulate controls with "well known names" to control e.g. output volume. The names it uses are probably based on Documentation/sound/alsa/ControlNames.txt, since the code was originally written for x86 platforms that use those names.
Is that document relevant to ASoC, up-to-date, and binding on audio drivers, or more of a de-facto FYI?
This basically doesn't work for ASoC - it is kind of what you should do if you can do things but it really only works for PC style sound cards where there's relatively little flexibility in terms of routing and so on. With embedded systems the appropriate controls to use for a given feature can vary substantially depending on board design and even use case (the CPU to headphone case for MP3 playback may not share anything at all with the voice call to earpiece) so it's difficult to do anything.
The idea with ASoC is that you should use UCM for this. What I'd suggest is that ChromeOS implements UCM support and then falls back to using control names if there isn't a UCM configuration for the device.
Those names don't exist for Tegra, or rather the WM8903, and I imagine for any ASoC drivers. I had imagined this could be fixed by creating virtual mixer controls in asound.conf that re-direct requests to that real control. Is that how things typically work? Or, should the ASoC machine driver create controls with those names?
Typically embedded applications don't try to work with generic control names at all - they're either specific to the physical system or use configuration files. A large part of what UCM does is abstract out the generic bits of the configuration files approach from applications.