On Wed, 2010-08-25 at 10:28 +0200, Jaroslav Kysela wrote:
On Tue, 24 Aug 2010, Liam Girdwood wrote:
On Mon, 2010-08-23 at 19:47 +0200, Jaroslav Kysela wrote:
Unfortunately, I have many ideas to improve the API before I can approve or recommend the inclusion to the alsa-lib's tree.
I wish you had shared your API ideas with us at the time of the RFC. A lot of time and effort has since went into UCM development :-/
I too. My big problem is the lack of time.
Same here, not enough hours in the day.
I tried to rethink the API to be more universal for future extensions (but the implementation will not dramatically change and the mechanisms you want to expose are not touched at all). I just wanted to add the possibility to create the virtual cards combining resources from any PCM/control/mixer device available in system. The proper device evaluation and mixer control assignments is something which is wanted by PulseAudio developers.
My proposed header file with reduced function set but not reduced functionality is available at:
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=include/use-case.h;h=33...
ok, that looks good.
The syntax of your proposed files is very close to the other alsa-lib's syntax. For example:
SectionModifier Name "Capture Voice" EnableSequence seq1 1 EndSequence QoS Voice EndSection
Can be written in alsa-lib's syntax:
SectionModifier."Capture Voice" [ EnableSequence [ seq1 1 ] QoS Voice ]
So I'm thinking to recode all parsers to use the alsa-lib configuration parsers. As bonus, the alsa-lib configuration routines give us some runtime evaluation and possibility to reference (include) other files.
ok, I agree here too.
Next step may be to support the 'amixer' like syntax for the control and mixer element handling.
Btw, we need to try and avoid using the control ID in any mixer syntax. I found that minor driver changes could change ID numbering meaning major updates to config files. The mixer names are pretty constant and using them has been quite painless.
Thanks
Liam