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 E85FFC433EF for ; Mon, 13 Dec 2021 08:19:49 +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 2346D18F0; Mon, 13 Dec 2021 09:18:58 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 2346D18F0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1639383588; bh=ZUscJyXcX7/bT3q5BnrTWQ2/qkYhCCgQht5lq2swM/s=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=nSwDwLBd8CVRljTbEKsuZvQu4TMhTYBebdxVvhCCN6B7K5C28UE3Eqcu7x1vcemiS DSHIQuhhkNezJBY3bRaxkc/p7WtRLGoA4fggP//0w0nDFjUx37nPPY0S/B5X7Ux0bJ 3VXaI5CepBRjWRi+K3UOdtq6QwES+62PqG5cFunA= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 9A16DF80161; Mon, 13 Dec 2021 09:18:57 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 1A628F8025D; Mon, 13 Dec 2021 09:18:56 +0100 (CET) Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) (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 DB2D8F80161 for ; Mon, 13 Dec 2021 09:18:47 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz DB2D8F80161 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="gUycapgB"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="t/jJ4T2R" Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 1C1B61F3B0; Mon, 13 Dec 2021 08:18:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1639383527; 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=s1pbLAgQpI4YpnyQCFn6LMltqC2ekuWHrp+/q0o+q9A=; b=gUycapgBix/EipS3V4kaomxthbcKlDxjshRO5SLWAl1Boq8CZTfyGe1MbPf8yCDXSQcUDR lrc2tgdRmlTH88/csTHQtZsnYxgEK9ehp+3mSHNQmsFh2JTOwD2JbfDc9Gg44BYNHn+Gud I3jj/YbrLbSvE5oGu8X061qBaemxsnY= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1639383527; 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=s1pbLAgQpI4YpnyQCFn6LMltqC2ekuWHrp+/q0o+q9A=; b=t/jJ4T2RGg3aGXnHrgn8CG/U8vndMgo6F2BKx7uqLF49oxwtXLrxFkug6Sx5abKCQ5kSOJ GnJRO3BnVAgJHfCQ== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 1633EA3B83; Mon, 13 Dec 2021 08:18:47 +0000 (UTC) Date: Mon, 13 Dec 2021 09:18:47 +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: 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 Mon, 13 Dec 2021 09:02:46 +0100, Takashi Sakamoto wrote: > > Hi, > > On Mon, Dec 13, 2021 at 08:20:38AM +0100, Takashi Iwai wrote: > > 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. > > Thank you, and I overlooked that the patch still includes C99 style > comment in the part for UAPI header... I'm preparing to fix it. Ahh, yeah, that was the reason I dropped your patch later. Takashi