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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
