On Mon, 2007-10-22 at 18:50 +0800, Leijin Tang wrote:
Hi
Thanks for the Takashi's idea. It's agreement that controlling the scenarios is needed in thealsa-lib. To the mobile device, the policy about the router switch or volume control is so complex that we can't resolve all issues by modified the alsa-lib.
Whether we can develop a simple server which carries out the policy?
But we still need define the control element, it's very important to the server's portability. Because the definition makes BSP to write driver which have the same interface.
The current zaurusd (policy/scenario manager for OpenZaurus) manages the complete and complex audio routing atm very well without any new control elements. It does this by having an asound.state for each scenario and a driver that exposes all it's audio controls. This way it's covers all possible routes within the sound card.
I'm now beginning to think it may be quick and easy to turn some of alsactl into a separate lib (from alsa-lib) and reuse it's file format and store/restore code for scenarios. A new master scenario file could then be added that will list the supported scenarios. e.g.
scenario { name = "phone call handset" # standard name file = "/path/to/phone-call-handset.state" alias master playback volume = 1 # number is control id from state file }
(This format is up to the implementer)
This new file would be parsed by the scenario lib and would allow apps to get/set/list scenarios. It would also allow the aliases to be queried by any device manager daemon/application (in order to update any volume controls).
Liam