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=-10.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,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 439F1C433E0 for ; Fri, 26 Feb 2021 09:23:47 +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 42E4164F3B for ; Fri, 26 Feb 2021 09:23:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 42E4164F3B 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 A9229825; Fri, 26 Feb 2021 10:22:52 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz A9229825 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1614331422; bh=cnLCYA4zjSbFuMbAP29kuoM9rMZyxKZbh9qbOJ4bX7w=; h=Subject:To:References:From:Date:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=rOZ5LVpK/YfwPBQZ8daKNohPL8VtyjMHmtPlzO7jr8Gv/V9eVvyVKt6mHenefagqe vQmkRrDe0QJrwstRoodFDh8dxhMuIGaVJIfLpRn97HtF9/0szRuPBcSkf8sr3XVA4P AlYT/uWwxZzYKsgP7Y25vG5vfxjgJVZ+TOr9kewU= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 35C76F80161; Fri, 26 Feb 2021 10:22:52 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 5B75EF8016C; Fri, 26 Feb 2021 10:22:50 +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 97571F80154 for ; Fri, 26 Feb 2021 10:22:44 +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 F05C3A003F; Fri, 26 Feb 2021 10:22:43 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.perex.cz F05C3A003F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perex.cz; s=default; t=1614331364; bh=3etpEoyxH3/PFV2Q/y2hXEWsTeTHDhDNBJgbMNY0gaQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=4admDCHkFXzUdndcw89OvTXFga5z6oh5zqG1HY3iPdvV/HyqYELwb72i43J+u6y1q WbassL3mY/s0il/WxyGEkcgR/7nE1i5hHgosgl2SnAqlF/whvNjaS2qFMiO1N1LdE2 i04sxYDfMNF7TzbRV6JRTKhtoCvzon60rO3JMVyA= Received: from p1gen2.localdomain (unknown [192.168.100.98]) (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; Fri, 26 Feb 2021 10:22:36 +0100 (CET) Subject: Re: [RFC 2/2] ASoC: rt5670: Add LED trigger support To: Takashi Iwai References: <20210215142419.308651-1-hdegoede@redhat.com> <20210215142419.308651-3-hdegoede@redhat.com> <20210223134506.GF5116@sirena.org.uk> <578b1ee3-f426-c5b5-bc78-5a91108ebdc8@redhat.com> <20210223140930.GH5116@sirena.org.uk> <5c6a21c1-7107-3351-25be-c007b0b946d3@perex.cz> <776b4ad9-2612-b08a-cb76-c3e1ce02388a@perex.cz> <4574088a-4676-131a-0065-499a516f80ae@perex.cz> <03068e15-2157-3ae6-ffd6-7ec315bb49a3@perex.cz> <9c74e8de-769c-cd98-3944-85bd75bc840b@perex.cz> <3c262ea6-2313-3af8-60ae-d59ae8be262d@perex.cz> <254af1a7-6ed4-60be-01b5-76cf08b7f8da@perex.cz> From: Jaroslav Kysela Message-ID: <0216951d-78bc-ca08-7aeb-7d3a79eceb91@perex.cz> Date: Fri, 26 Feb 2021 10:22:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Cc: Oder Chiou , alsa-devel@alsa-project.org, Liam Girdwood , Hans de Goede , Mark Brown , Bard Liao 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: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Dne 26. 02. 21 v 9:41 Takashi Iwai napsal(a): > On Thu, 25 Feb 2021 19:09:44 +0100, > Jaroslav Kysela wrote: >> >> Dne 25. 02. 21 v 12:00 Takashi Iwai napsal(a): >>> On Wed, 24 Feb 2021 18:57:42 +0100, >>> Jaroslav Kysela wrote: >>>> >>>> Dne 24. 02. 21 v 13:42 Takashi Iwai napsal(a): >>>>> On Wed, 24 Feb 2021 13:08:55 +0100, >>>>> Jaroslav Kysela wrote: >>>>>> >>>>>> Dne 24. 02. 21 v 12:43 Takashi Iwai napsal(a): >>>>>> >>>>>>>>> So far, a user control is merely storing the value, let read/write via >>>>>>>>> the control API. That's all, and nothing wrong can happen just by >>>>>>>>> that. Now if it interacts with other subsystem... >>>>>>>>> >>>>>>>>> A more serious concern is rather the fragility of the setup; for >>>>>>>>> enabling the mute LED control, you'd have to create a new user-space >>>>>>>>> control, the function of the control has to be ignored by some >>>>>>>>> application and some not, etc. This has to be done on each machine >>>>>>>> >>>>>>>> You're using "ignore", but as I explained before, the user space switch will >>>>>>>> be used in the whole chain: >>>>>>>> >>>>>>>> capture stream -> >>>>>>>> alsa-lib mute switch / silence PCM stream -> >>>>>>>> PA mute switch / silence PCM stream >>>>>>>> >>>>>>>> So PA can use this switch like the traditional hardware mute switch. >>>>>>> >>>>>>> Does it mean PA would work as of now without any change? Or does it >>>>>>> need patching? >>>>>> >>>>>> Yes, no PA modifications are required with my mechanism. The PA will just see >>>>>> the new user space control - mute switch - created in alsa-lib - which will be >>>>>> synced the internal PA path mute state like for the hardware mute >>>>>> switch. >>>>> >>>>> OK, but how would we create and manage the user control element? And >>>>> why it has to be user control? >>>> >>>> The softvol or alsactl can create the user control element. The alsa-lib >>>> softvol plugin and PA can silence stream according the state. >>> >>> And that's tricky if it's only with PA, as PA won't open a softvol PCM >>> stream... >> >> The protection is in alsa-lib, so we can skip to check this hint flag for this >> particular case like: >> >> https://github.com/alsa-project/alsa-lib/pull/121/commits/1acc1c7eccab0359996b25de54a6b6e0aa1e0c17 >> >> So it may depend on the softvol config not PA itself. > > Thanks, that's what I missed from the big picture. > >> Even for the solution bellow, we need to modify softvol to handle the kernel >> control elements, too. Actually softvol is not active, when the specified >> control element is found and this element is not from the user space. > > Hm, that would certainly work, but as we discussed before, it enforces > the softvol PCM process for PA. That isn't too bad for the capture, > fortunately, but not ideal, OTOH. PA can work without softvol in this case, but in my opinion, it may be better to force the silence in UCM (do not depend only on the implementation of the UCM application - like PA - more security). As I wrote before, the silencing can be done in alsa-lib AND in PA (simultaneously). If we use only mute switch control configuration (on/off - not volume) for sofvol, then the code in alsa-lib is really effective without any performance penalty. > And, I'm not sure how PA can take any control as its main capture mute > switch, if it's named differently. Wouldn't we need to change mixer > path in PA as well? And, if we may change PA side, it sounds more > natural to change a control directly in PA's mixer path. The softvol > doesn't fit well with PA, after all. The ACP microphone is handled via UCM, so we can add the new control switch identifier to UCM. No PA modifications should be required. And the LED state can be handled via the phantom control (AMD ACP) + legacy HDA capture switch. So two controls from two different sound cards may be marked with the LED microphone group, if it's the correct way for users. Jaroslav -- Jaroslav Kysela Linux Sound Maintainer; ALSA Project; Red Hat, Inc.