Re: [alsa-devel] UCM extensions

[Jaroslav Kysela <perex@perex.cz>]

Dne 07. 11. 19 v 12:16 Takashi Iwai napsal(a):
> On Thu, 07 Nov 2019 12:08:26 +0100,
> Jaroslav Kysela wrote:
>>
>> Dne 07. 11. 19 v 10:23 Takashi Iwai napsal(a):
>>> 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.
>>
>> Ok, I can move the new configs to ucm2 (/usr/share/alsa/ucm2) and
>> leave the original directory empty (as fallback), because all configs
>> can be modified to support the right card identificator (kernel module
>> id parameter) rather than the hard coded default value generated by
>> the ALSA core kernel code.
>>
>> But there is an issue with the environment variable "ALSA_CONFIG_UCM"
>> which specifies directly the directory. We cannot predict the syntax
>> for it.
> 
> Right, that's a bit of headache.  Another idea would be to we put
> under /usr/share/alsa/ucm/v2/... and the parser starts looking at
> $ALSA_CONFIG_UCM/v$VERSION/... then falls back to the
> $ALSA_CONFIG_UCM/...
> 
> But I'm really open for any other options, too.

I would probably vote for this:

/usr/share/alsa/ucm2	- new configs with 'Syntax' field protection
/usr/share/alsa/ucm	- old configs

ALSA_CONFIG_UCM2	- env path for the new configs
ALSA_CONFIG_UCM		- env path for the old configs

					Jaroslav

-- 
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