From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BA916C5DF61 for ; Thu, 7 Nov 2019 11:17:18 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 39C3621882 for ; Thu, 7 Nov 2019 11:17:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="fpPd8xyC" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 39C3621882 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id D87DD1673; Thu, 7 Nov 2019 12:16:25 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz D87DD1673 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1573125435; bh=Aad08POXXldVyuK4zgPx1JLpzy46/ufFEEPieVGh1o4=; h=Date:From:To:In-Reply-To:References:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=fpPd8xyCH972cwbXfyMgzIXTEJOI8HPYjRw7yAO6lEOSZLhMA1wcIYncgzus1JfPV w8obrflvevGwJB7FqFHlQE4IAEoQTyNVy985AZD9kP6ooanEbTA46SFU0oQjQF4znP piKJRPq5xQBMNBiOeHm6p7oYjSLDCP+jTJ7XBaSo= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 718D6F80446; Thu, 7 Nov 2019 12:16:25 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 4B20BF8049B; Thu, 7 Nov 2019 12:16:24 +0100 (CET) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id C697EF80111 for ; Thu, 7 Nov 2019 12:16:21 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz C697EF80111 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 8BF62B3B8; Thu, 7 Nov 2019 11:16:20 +0000 (UTC) Date: Thu, 07 Nov 2019 12:16:20 +0100 Message-ID: From: Takashi Iwai To: Jaroslav Kysela In-Reply-To: <822f8c3d-b4fc-98ca-d749-e9f2f638e6e9@perex.cz> References: <6dcc3e0d-0df5-90cf-220f-59253d3b5c7c@perex.cz> <608ff861-9c2a-e498-3ec9-4fe09f2583e6@perex.cz> <822f8c3d-b4fc-98ca-d749-e9f2f638e6e9@perex.cz> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: ALSA development , Mark Brown , Kai Vehmanen Subject: Re: [alsa-devel] UCM extensions X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" 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@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel