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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 41431C433EF for ; Mon, 13 Dec 2021 07:21:40 +0000 (UTC) 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 4E57D17CF; Mon, 13 Dec 2021 08:20:48 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 4E57D17CF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1639380098; bh=nCmncDTzdWesOw1iqDAHIL4sHKVVEacTfK5uVCfHubE=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=U4yYHasL4GDqwCAM4rInAVc539CpZYQesxEEgWuvv4QpTd/VbwoEMZ9UqCR//9Om1 ZUiqhGyOgeRN3kP+eHyXTtppMThiAjZFXT7XcP3ytjNUbC+mcgo6tcEp8f614u8l77 pONsZHnjKZ5L0/O/gRuP2DSks9TBnzXLfy2MeT1I= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id D14F7F8016A; Mon, 13 Dec 2021 08:20:47 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 2C0D8F8025D; Mon, 13 Dec 2021 08:20:46 +0100 (CET) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 6B122F8016A for ; Mon, 13 Dec 2021 08:20:39 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 6B122F8016A Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="E//4t9bt"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="OSU46vMQ" Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 697FD210F4; Mon, 13 Dec 2021 07:20:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1639380039; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cpXSxvt9Ir8XvdbKQV4mLAZE1cR+Yom23PX2QcCQEIM=; b=E//4t9btOcX2ecP4w19tKqSth9d8K2uyVx93DWqHl4IxtOVqHnoUZ1CkjpWG86KcFkdzUi CvhGSGs9CTxIdmX6P8sxNkFC2hTTRgeQZrnRTKZ0UiyzT2kFFN6VYkzb4hiEB4vIEIgpR7 VVLFiO4G7TkqUP1Ama0ABrjVS90Dm9I= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1639380039; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cpXSxvt9Ir8XvdbKQV4mLAZE1cR+Yom23PX2QcCQEIM=; b=OSU46vMQHDvwftBJGi+5SWo8td0P8MtMvo50K+FN5u69ZXNxHQs85HdRJSKstc1ySUv+UJ bNn63A+1lWgpG5AA== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 5A016A3B89; Mon, 13 Dec 2021 07:20:38 +0000 (UTC) Date: Mon, 13 Dec 2021 08:20:38 +0100 Message-ID: From: Takashi Iwai To: "Takashi Sakamoto" Subject: Re: [PATCH] ALSA: pcm: comment about relation between msbits hw parameter and [S|U32] formats In-Reply-To: <30685ab6-3347-43ee-b20d-6e11994242b4@www.fastmail.com> References: <20210529033353.21641-1-o-takashi@sakamocchi.jp> <30685ab6-3347-43ee-b20d-6e11994242b4@www.fastmail.com> 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") Content-Type: text/plain; charset=US-ASCII Cc: alsa-devel@alsa-project.org 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" On Sun, 12 Dec 2021 12:30:30 +0100, Takashi Sakamoto wrote: > > Hi, > > On Sun, May 30, 2021, at 16:32, Takashi Iwai wrote: > > On Sat, 29 May 2021 05:33:53 +0200, > > Takashi Sakamoto wrote: > >> > >> Regarding to handling [U|S][32|24] PCM formats, many userspace > >> application developers and driver developers have confusion, since they > >> require them to understand justification or padding. It easily > >> loses consistency and soundness to operate with many type of devices. In > >> this commit, I attempt to solve the situation by adding comment about > >> relation between [S|U]32 formats and 'msbits' hardware parameter. > >> > >> The formats are used for 'left-justified' sample format, and the available > >> bit count in most significant bit is delivered to userspace in msbits > >> hardware parameter (struct snd_pcm_hw_params.msbits), which is decided by > >> msbits constraint added by pcm drivers (snd_pcm_hw_constraint_msbits()). > >> > >> In driver side, the msbits constraint includes two elements; the physical > >> width of format and the available width of the format in most significant > >> bit. The former is used to match SAMPLE_BITS of format. (For my > >> convenience, I ignore wildcard in the usage of the constraint.) > >> > >> As a result of interaction between ALSA pcm core and ALSA pcm application, > >> when the format in which SAMPLE_BITS equals to physical width of the > >> msbits constaint, the msbits parameter is set by referring to the > >> available width of the constraint. When the msbits parameter is not > >> changed in the above process, ALSA pcm core set it alternatively with > >> SAMPLE_BIT of chosen format. > >> > >> In userspace application side, the msbits is only available after calling > >> ioctl(2) with SNDRV_PCM_IOCTL_HW_PARAMS request. Even if the hardware > >> parameter structure includes somewhat value of SAMPLE_BITS interval > >> parameter as width of format, all of the width is not always available > >> since msbits can be less than the width. > >> > >> I note that [S|U24] formats are used for 'right-justified' 24 bit sample > >> formats within 32 bit frame. The first byte in most significant bit > >> should be invalidated. Although the msbits exposed to userspace should be > >> zero as invalid value, actually it is 32 from physical width of format. > >> > >> Signed-off-by: Takashi Sakamoto > > > > Thanks, applied. > > > > > > Takashi > > I can not find the patch in your tree. Would I ask you to review again? Hrm, it seems that the commit was lost by some reason. Sorry! > If it should be going to be applied, I'd like you to fix my typo in the subject line; > > * "[S|U32]" -> "[S|U]32" There was another similar typo in the patch description and I corrected both. Now applied to for-next, commit fb6723daf89083a0d2290f3a0abc777e40766c84. thanks, Takashi