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.
Best Regards, Libin
Jaroslav-- Jaroslav Kysela perex@perex.cz Linux Sound Maintainer; ALSA Project; Red Hat, Inc.