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 96A8AC3DA4A for ; Fri, 9 Aug 2024 19:27:55 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id B94C814E7; Fri, 9 Aug 2024 21:27:43 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz B94C814E7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1723231673; bh=EjHqHHKYoRZX3HoUBZAvpzA3I2pO6ift5GDZ3LPhRnc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=se12loK1/ywl3XMGM9gjJuiAJ2TxAgJNiyZdxjzwd7sNzxAFyTEq+XvM7ohkz1F8O RQ68iTAW5iFQ4kXhXYVGpOpYUzcq1dPE43vAHYi2Ix3/pz5QVGNyRHjIDBLVGEG32e tZ5XmgTr31f+vROuCQ0I4DXR00V0jI4Zw/hZh2eU= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 9BEB3F8057A; Fri, 9 Aug 2024 21:27:23 +0200 (CEST) Received: from mailman-core.alsa-project.org (mailman-core.alsa-project.org [10.254.200.10]) by alsa1.perex.cz (Postfix) with ESMTP id D49DFF805B5; Fri, 9 Aug 2024 21:27:22 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id AB678F802DB; Fri, 9 Aug 2024 21:22:12 +0200 (CEST) Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id A2548F8059F for ; Fri, 9 Aug 2024 21:20:49 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz A2548F8059F Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=BY82d7Gx DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1723231251; x=1754767251; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=EjHqHHKYoRZX3HoUBZAvpzA3I2pO6ift5GDZ3LPhRnc=; b=BY82d7Gx1Q4HrVajP7IkWbWt7hCaA7HbJSWOduwUEIo8n/CwurPrA2kH 3wW8Tmx1a//Z588h8MMgeW1AM1+CkrRm+FOUT61/gjp5+Fwe727PZHqHM s28jWOpjNwMoCxWLiOSNEZvff8NvHRnEkf/HnkLPV3bIsq9EyL/mdWglx xBjzXJf+fq8X+sjmsKJkCL8KNnxR006vqFXc5orx+bYr1aoaGcHxpfEGM yOtxvQn4rweZO2eNW7wcFFp40TjgrczeWsD4UZEK9pjtOGp/+40B4HaA/ bqWkenvmTICECpdcaHTbrVq9mrKrCzs7FWpQouSGW7QKfmrDLN1hCT2o2 A==; X-CSE-ConnectionGUID: nZwAjSZRRoSemIY2ydQUeQ== X-CSE-MsgGUID: fe/B8iWMSly4Rr0SfQyr/g== X-IronPort-AV: E=McAfee;i="6700,10204,11159"; a="25285244" X-IronPort-AV: E=Sophos;i="6.09,277,1716274800"; d="scan'208";a="25285244" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2024 12:20:45 -0700 X-CSE-ConnectionGUID: WCOiZLDZT+WOhIWdX/i3CQ== X-CSE-MsgGUID: UZY+OjWrRDqm300lv/H98g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,277,1716274800"; d="scan'208";a="61793214" Received: from kniemiec-mobl1.ger.corp.intel.com (HELO [10.245.246.249]) ([10.245.246.249]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Aug 2024 12:20:41 -0700 Message-ID: Date: Fri, 9 Aug 2024 21:20:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/6] ALSA: compress: add Sample Rate Converter codec support To: Jaroslav Kysela , Shengjiu Wang Cc: Shengjiu Wang , vkoul@kernel.org, tiwai@suse.com, alsa-devel@alsa-project.org, linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org, Xiubo.Lee@gmail.com, festevam@gmail.com, nicoleotsuka@gmail.com, lgirdwood@gmail.com, broonie@kernel.org, linuxppc-dev@lists.ozlabs.org References: <1722940003-20126-1-git-send-email-shengjiu.wang@nxp.com> <1722940003-20126-2-git-send-email-shengjiu.wang@nxp.com> <116041ee-7139-4b77-89be-3a68f699c01b@perex.cz> <930bb152-860a-4ec5-9ef0-1c96f554f365@linux.intel.com> <542d47c5-7ce3-4c17-8c0a-3a2b2a9e6c6a@linux.intel.com> Content-Language: en-US From: Pierre-Louis Bossart In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-ID-Hash: WLRR7DBYVFO5PMLXIWCXTAN5SDHTSKMK X-Message-ID-Hash: WLRR7DBYVFO5PMLXIWCXTAN5SDHTSKMK X-MailFrom: pierre-louis.bossart@linux.intel.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-alsa-devel.alsa-project.org-0; header-match-alsa-devel.alsa-project.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: >>> And metadata >>> ioctl can be called many times which can meet the ratio modifier >>> requirement (ratio may be drift on the fly) >> >> Interesting, that's yet another way of handling the drift with userspace >> modifying the ratio dynamically. That's different to what I've seen >> before. > > Note that the "timing" is managed by the user space with this scheme. > >>> And compress API uses codec as the unit for capability query and >>> parameter setting,  So I think need to define "SND_AUDIOCODEC_SRC' >>> and 'struct snd_dec_src',  for the 'snd_dec_src' just defined output >>> format and output rate, channels definition just reuse the >>> snd_codec.ch_in. >> >> The capability query is an interesting point as well, it's not clear how >> to expose to userspace what this specific implementation can do, while >> at the same time *requiring* userpace to update the ratio dynamically. >> For something like this to work, userspace needs to have pre-existing >> information on how the SRC works. > > Yes, it's about abstraction. The user space wants to push data, read > data back converted to the target rate and eventually modify the drift > using a control managing clocks using own way. We can eventually assume, > that if this control does not exist, the drift cannot be controlled. > Also, nice thing is that the control has min and max values (range), so > driver can specify the drift range, too. This mode of operation would be fine, but if you add the SRC as part of the processing allowed in a compressed stream, it might be used in a 'regular' real-time pipeline and the arguments and implementation could be very different. In other words, this SRC support looks like an extension of the compress API for a very narrow usage restricted to the memory-to-memory case only. I worry a bit about the next steps... Are there going to be other types of PCM processing like this, and if yes, how would we know if they are intended to be used for the 'regular' compress API or for the memory-to-memory scheme?