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=-7.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 63D66C5DF61 for ; Thu, 7 Nov 2019 13:16:05 +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 DC71221D6C for ; Thu, 7 Nov 2019 13:16:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="lS5OeTCI"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=perex.cz header.i=@perex.cz header.b="hKWQAxEl" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC71221D6C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=perex.cz 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 07B4C1696; Thu, 7 Nov 2019 14:15:13 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 07B4C1696 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1573132563; bh=86z6LRYejrXQCgOVGKx2uL7BRKFDvedaW/Q2EDanxCQ=; h=To:References:From:Date:In-Reply-To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=lS5OeTCIigZ490Bg1gUxl/nfrYoi+xjdz0JnJUGpFosJ9QuK66VkOoHWadDMfiU7a TpNNEWglXspkzaEWKOf8vZzSyNZ7wv/5reY46RDbpb/+MjTV6ASh8xz1qTgM43T+s4 LKN2n9d3fOMsRX+M/yGVZGva39FpUWPMPG7P6U64= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 7A3B6F8049B; Thu, 7 Nov 2019 14:14:36 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id E83B4F8053B; Thu, 7 Nov 2019 14:14:34 +0100 (CET) Received: from mail1.perex.cz (mail1.perex.cz [77.48.224.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 8D709F80111 for ; Thu, 7 Nov 2019 14:14:31 +0100 (CET) Received: from mail1.perex.cz (localhost [127.0.0.1]) by smtp1.perex.cz (Perex's E-mail Delivery System) with ESMTP id 78704A0042; Thu, 7 Nov 2019 14:14:31 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.perex.cz 78704A0042 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perex.cz; s=default; t=1573132471; bh=EmqTkMlOcKiK0QPkViLVcBHsKCrjX7QWriz+gudYTso=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hKWQAxElfO5x4ZG9v68CdQNXXTsfDKvdaS9sHWtT4GgHx4113RzR0lsqBw3nAxdct w2YKP+fSobCYH7sK8GA/cyuIjEkW1GEEejs9dkJ3wDdus8IPmqhr88FjDkBySzZ6Us KfbtadWzB/lWN8hybEs1dqyK6jUcR4P+hb8CPEaI= Received: from p50.perex-int.cz (unknown [192.168.100.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: perex) by mail1.perex.cz (Perex's E-mail Delivery System) with ESMTPSA; Thu, 7 Nov 2019 14:14:27 +0100 (CET) To: Takashi Iwai References: <6dcc3e0d-0df5-90cf-220f-59253d3b5c7c@perex.cz> <608ff861-9c2a-e498-3ec9-4fe09f2583e6@perex.cz> <822f8c3d-b4fc-98ca-d749-e9f2f638e6e9@perex.cz> From: Jaroslav Kysela Message-ID: <8f7da616-caa9-5af7-e00b-812d65444171@perex.cz> Date: Thu, 7 Nov 2019 14:14:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" 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 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