Re: [alsa-devel] UCM extensions

[Jaroslav Kysela <perex@perex.cz>]

Dne 07. 11. 19 v 11:18 Cezary Rojewski napsal(a):
> On 2019-11-05 20:36, Jaroslav Kysela wrote:
>> Hi all,
>>
>>       I make some internal ucm code cleanups in alsa-lib and added three
>> major extensions to allow more complex configurations which we require
>> for the SOF kernel driver.
>>
>>       The first thing is the added substitution for the value strings:
>>
>> https://github.com/alsa-project/alsa-lib/commit/f1e637b285e8e04e6761248a070f58f3a8fde6fc
>>
>>
>>       The second thing is the If block:
>>
>> https://github.com/alsa-project/alsa-lib/commit/985715ce8148dc7ef62c8e3d8ce5a0c2ac51f8df
>>
>>
>>       The third thing is the card / hardware like specifier passed as the
>> ucm name to snd_use_case_mgr_open() to support multiple card instances:
>>
>> https://github.com/alsa-project/alsa-lib/commit/60164fc5886cdc6ca55eeed0c2e3f751a7d2b2c0
>>
>>
>>       All those patches (with other cleanups) are in the ucm2 branch on
>> github for comments:
>>
>> https://github.com/alsa-project/alsa-lib/commits/ucm2
>>
>>       The proposed SOF UCM config diff is here:
>>
>> https://github.com/alsa-project/alsa-ucm-conf/commit/723b6da881721488229154e923ed36413955a051
>>
>> https://github.com/alsa-project/alsa-ucm-conf/commits/ucm2
>>
>>       I added everything to keep the interface backward compatible, so
>> the current applications should not observe any different behavior. The
>> applications like pulseaudio should use the 'hw:CARD_INDEX' specifier
>> for the open call in the future and snd_use_case_parse_ctl_elem_id()
>> helper for the element control names.
>>
>>       If you have another ideas to address those issues, please, let me
>> know.
>>
>>       BTW, Mark: The SOF UCM configs relies on the driver name changes,
>> so it might be worth to send "ASoC: intel - fix the card names" patch to
>> 5.4 to make things stable more quickly:
>>
>>       https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?h=for-5.5&id=d745cc1ab65945b2d17ec9c5652f38299c054649
>>
>>                   Thanks,
>>                       Jaroslav
>>
> 
> 
> Thanks for your work, Jaroslav.
> 
> However, I have some concerns here. First, could you elaborate on "we
> require for the SOF kernel driver"?

Please, look here:

https://github.com/alsa-project/alsa-ucm-conf/commit/a8253465aef2df494ccd5b1103412b0318be582e#diff-a2ba34aee1a55c2fd664d78624477173L37

The HDA driver sometimes manages different JackControl names depending on the 
used codec and it would be the real maintenance mess to use the DMI info (long 
card name) for all possible configurations.

Also, if you look to the current configs, many duplications can be removed 
with the If evaluations.

> The substitutions and multi-instance support is probably warmly welcomed
> by many, but "If" blocks are what worries me. Especially the nested
> "Ifs". As Takashi pointed already out, UCM - which is currently is
> viewed as a simple configuration syntax - is becoming a language on its
> own. If we are to keep extending UCM on and on, we might as well switch
> to JSON/ XML/ YAML entirely instead of developing our own thingy.

The configuration syntax itself is really close to JSON, it's just about the 
run-time evaluation of some blocks at the load time. The different static 
syntax format does not help us so much.

> "If" block could just be what's needed to open new pandora box, allowing
> for very complex and no longer easy-to-read config files. In general, if
> one is to enlist an "If", why not define two UCMs instead?

For HDA, USB or and drivers with many hardware variants, the managing of 
thousands of files will be the real nightmare. Also, at some point, I would 
like to create the use case configs for all hardware, thus pulseaudio or any 
other server (maybe pipewire in the future) can use the use case configuration 
to abstract fully the hardware without their own profiles or so... The goal is 
to have this in the one place.

> Moreover, I see you mentioning the card-name dependency. This sounds
> rather invasive. Separation of different config-versions would be required.

What do you mean with this?

					Jaroslav

> 
> Czarek
> 


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel