[alsa-devel] UCM extensions

[Takashi Iwai]

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.


thanks,

Takashi