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/f1e637b285e8e04e6761248a070f...
The second thing is the If block:
https://github.com/alsa-project/alsa-lib/commit/985715ce8148dc7ef62c8e3d8ce5...
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/60164fc5886cdc6ca55eeed0c2e3...
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/723b6da881721488229154e...
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=...
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/a8253465aef2df494ccd5b1...
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