[alsa-devel] ALSA UCM

[Jaroslav Kysela]

On Fri, 12 Nov 2010, Liam Girdwood wrote:

> On Fri, 2010-11-12 at 17:25 +0100, Jaroslav Kysela wrote:
>> On Fri, 12 Nov 2010, Liam Girdwood wrote:
>>
>>> On Wed, 2010-11-10 at 16:11 +0100, Jaroslav Kysela wrote:
>>>> On Tue, 9 Nov 2010, abraham duenas wrote:
>>>>
>>>
>>>>> I'm getting the expected error ONLY for the last element: listed in
>>>>> the EnableSequence field:
>>>>> e.g:
>>>>> ALSA lib main.c:137:(execute_sequence) cset not yet implemented:
>>>>> 'name='DL2 Media Playback Volume' 90'
>>>>> ALSA lib main.c:137:(execute_sequence) cset not yet implemented:
>>>>> 'name='MUX_UL10' 10'
>>>>>
>>>>> i'll keep on digging as time permits :)
>>>>
>>>> I fixed the sequence parser. It should work now ok. So the only missing
>>>> part is to add the 'snd_ctl_*' backend for cset commands. The parsing
>>>> functions for ctl strings are available in my ucm branch now:
>>>
>>> Is it the intention to reuse the cset functionality from amixer here ?
>>
>> Yes, basically to avoid double ASCII syntax for same thing. I expect that
>> the amixer will be recoded to use parser functions implemented in
>> alsa-lib.
>
> Ok, so with any luck this will mostly involve copy and pasting the cset
> code from amixer and alsa-lib.

It's done :-) The only missing part is the integration of this code to 
UCM. Note that my UCM implementation does not assume that only one 
soundcard can be touched, so we probably need additional command to select 
the ctl device for which will be cset commands applied. Also, Mark said 
something that your code used some transformations for controls to specify 
how the controls will be changed, but not-specified controls will be set 
from previous (probably default) state, something like this:

1) default initalization - grab actual control values from driver and
    overwrite with specified values from the configuration file (it can be
    just subset of all controls provided from the driver)
2) setting verb/mod etc.. - specify just changes for the default state

I think that we can do this with some named control sets and adding 
commands like:

create_cset (optional filter - which values should be handled or all if
 	     not specified)
handle_cset - operate with initial or current values (maybe we can have
               two commands to distincts this behaviour)
  ... all new cset commands to change the named cset ...
apply_cset - push (write) whole cset to the driver

Eventually commands like copy_cset etc. might be implemented. There are 
plenty of possibilities. My point is that the UCM behaviour should be 
specified in the configuration files without any hardcoded things.

 					Jaroslav

-----
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.