On Thu, 07 Nov 2019 09:33:27 +0100,
Jaroslav Kysela wrote:
Dne 07. 11. 19 v 7:48 Takashi Iwai napsal(a):
On Tue, 05 Nov 2019 20:36:28 +0100,
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.
The only concern with these extensions so far is the compatibility.
Imagine that people run the new profile on the old parser, it'd break
easily.
I think other scripts often installing on the versioned directory if
incompatibilities are seen. Can we do that for UCM as well?
Or course, once after UCM parser is changed to be future-ready and
allow some syntax for possible future extensions, we can keep that
version directory in future, too.
While we are going to separate UCM files from alsa-lib to
alsa-ucm-conf we can define the new syntax change until the first
version is released (I can put a notice to README).
Speaking for Fedora, we have dependancy 'alsa-lib package version'
must be equal to 'alsa-ucm package version'. If users will do any
changes on their own, they should know what they are doing.
This assumes that you have only one alsa-ucm package. If there is a
downstream version of UCM profile, this won't work well always.
Anyway, we should learn from this and I would propose to add add
something like 'Syntax 2' to the main configuration file now. The new
functions should be activated only according the version.
Yeah, some extensibility is needed in the config space.
Unfortunately, the current parser will just show an error message like:
ALSA lib parser.c:1337:(parse_master_file) uknown master file field Syntax
ALSA lib parser.c:1337:(parse_master_file) uknown master file field If
Right, that's the problem now. Even a non-existing control would lead
to an error with the current version of parser.
But at least, users should be notified that there is a configuration mismatch.
I don't think this would suffice. The new UCM config is not merely a
config but it's becoming rather a language, so this needs some
distinction from the current v1 files.
Another possibility is to change the suffix for the master
configuration file to accept the "Syntax" check for the another future
update. But honestly, I don't like ".conf2" and ".v2.conf" looks not
so nice, too.
My vote is for a different directory. And, with v2 extension, we
should leave the room for further extensibility, and keep the same
location as long as it's compatible. Keeping the location for
incompatible configs would lead to a mess.
