[alsa-devel] [alsa-lib][RFC PATCH] ucm: reset config id of condition items

[Jaroslav Kysela]

Dne 24. 04. 20 v 5:22 Yang, Libin napsal(a):
> Hi Jaroslav,
> 
>>>
>>> Can you clarify what the conflict is and what id you were referring to?
>>
>> The arrays in the ALSA configs are represented like:
>>
>> User syntax:
>>
>> name [
>>     value0
>>     value1
>> ]
>>
>> Internal tree:
>>
>> name.0 value0
>> name.1 value1
>>
>> or
>>
>> name {
>>     0 value0
>>     1 value1
>> }
>>
>> (all three syntaxes are equal, the array just removes the indexes for the
>> readability)
>>
>> This patch tries to change name.0 to something like name.unique-0 or so which
>> is not so much pretty.
>>
>> You can just declare the new sequences like this to avoid clash:
>>
>> EnableSequence.seq3.cset "name='PGA3.0 3 Master Playback Volume' 50"
> 
> I tried your suggestion, the code like:
> If.seq1p {
>          Condition {
>                  Type ControlExists
>                  Control "name='PGA1.0 1 Master Playback Volume'"
>          }
>          True {
>                  EnableSequence.seq1p.cset "name='PGA1.0 1 Master Playback Volume' 50"
>          }
> }
> 
> It seems not work. When I run "alsaucm -c sof-soundwire open sof-soundwire"
> It shows:
> ALSA lib parser.c:470:(parse_sequence) error: string type is expected for sequence command
> ALSA lib parser.c:1257:(parse_verb) error: failed to parse verb enable sequence
> ALSA lib parser.c:1370:(parse_verb_file) error: HiFi.conf failed to parse verb
> ALSA lib main.c:962:(snd_use_case_mgr_open) error: failed to import sof-soundwire use case configuration -22
> alsaucm: error failed to open sound card sof-soundwire: Invalid argument
> 
> My understanding is that "EnableSequence.seq1p.cset" will create
> a new snd_config_t "seq1p" between "EnableSequence" and "cset".
> This will cause executing EnableSequence failure.

Oops. I was too quick in the idea. The configuration is the tree inside memory 
and [] is just a special case where the ids are replaced with the continuous 
integer range, thus:

EnableSequence [
   cmd1 arg1
   cms2 arg2
]

is expanded to:

EnableSequence {
   0 cmd1
   1 arg1
   2 cmd2
   3 arg2
}

or

EnableSequence.0 cmd1
EnableSequence.1 arg1
EnableSequence.2 cmd2
EnableSequence.3 arg2

So if you like to add a new sequence which is outside the declared array, then 
you need to add this:

EnableSequence { cmdid3 cmd3 argid3 arg3 }

or (maybe more readable):

EnableSequence { cmdid3=cmd3 argid3=arg3 }

or:

EnableSequence.cmdid3 cmd3
EnableSequence.argid3 arg3

The ids names can be anything but they must be unique in the block (tree leaf).

The declaration order matters in this context (_arg_ must be right behind 
_cmd_ for the sequences). Note that the functions which works on top of the 
configuration tree (like the in-place evaluation - If blocks) are executed on 
top of this tree (which is parsed at first)! Keep it in the mind.

					Jaroslav

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