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 EC616CA1015 for ; Thu, 4 Sep 2025 13:19:05 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [45.14.194.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 930A4601F5; Thu, 4 Sep 2025 15:18:52 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 930A4601F5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1756991942; bh=wV0yfGoHn6c4KIaX2WQsVA1c9mDcZW4LX12hbAQmucQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-Id: List-Archive:List-Help:List-Owner:List-Post:List-Subscribe: List-Unsubscribe:From; b=hX7ece13yjo14Khj4+UHnkYm7evjbahAMbIqfdt+GYbncx3g7mmvX3VObBgXjsqJT iCH/uMHSUqLCkGdlM4rD+uIhjOEPL+TQn0uM2LehGMGzZ7/oFTbKAKpY5d0jRQbMAm YA9OTxsdj+5NkQy7Rr9YsMfW/m411tOXuObkUP/A= Received: by alsa1.perex.cz (Postfix, from userid 50401) id 85AD6F805C6; Thu, 4 Sep 2025 15:18:26 +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 3BF5EF805D2; Thu, 4 Sep 2025 15:18:26 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 43D73F804B0; Thu, 4 Sep 2025 15:18:18 +0200 (CEST) Received: from fhigh-b8-smtp.messagingengine.com (fhigh-b8-smtp.messagingengine.com [202.12.124.159]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 902E9F8011B for ; Thu, 4 Sep 2025 15:18:13 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 902E9F8011B Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=sakamocchi.jp header.i=@sakamocchi.jp header.a=rsa-sha256 header.s=fm1 header.b=adIwBHc9; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm1 header.b=eDe+8XFc Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.stl.internal (Postfix) with ESMTP id 29F927A03D0; Thu, 4 Sep 2025 09:18:12 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Thu, 04 Sep 2025 09:18:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sakamocchi.jp; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1756991892; x= 1757078292; bh=Iyuj87vy4e6aMmv8nQ0zfqnbJyUHJmzF1z8YFo4q9ig=; b=a dIwBHc9T6xDf/78BBY1uMfGBVqiZvdR8nQh4QyY4qux2PCCVm3+l3ksJOVBBNcB9 JK/kLqhRbl9xx1RxqvreD7pYrnAD72uLJ4scSMbuO2W8GOIzlqgxFz4yKiik0XIQ JnlB92u69fJBw4HoEVr2D1+5jTH7EY7/s04m5MWVg/c4tuTZdNUkheVyQV9Kj2EO qPbB+e9Da/VPM9tFbi0Q7e3LXhEvDjJqxd3NGoTenOS1a39aIfFQXBDTwl8zc401 82QgHBgH0FjVDHNE4+rOGRCqVXFBYGLxP2bW/6UbfRZFcvVG8/ljoVVf0w2gYEu+ ynPlmB0ztSWLQLJy5X43A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1756991892; x=1757078292; bh=Iyuj87vy4e6aMmv8nQ0zfqnbJyUHJmzF1z8 YFo4q9ig=; b=eDe+8XFck1zuFxUgiGOW0jjLfc2Az5sBkOvyJ/9Xsha8k8R3FXx dTHi8kkn5x6qmF8OMgxGmt1aVqs1KI+qkg54W/CNaXRDg34Rd0Fnka2gwcMwF9MO 4u112T5ullkaYPBuJm+J8ElyoIddudnuZP+2wJ7kNHtySbx27GLlRwobERTbkZOe AIt+tPMjbIA+tKIpXVXidzDLcgDsmPY3W31FfSh+Y5BFGdH93vZY9jkgjqXEds6O rbliW8dOE5YsZe+fpzyXlpfPkBr4gdem2mTYpntuxFNT+BbDVIX4z5BSN1za+M8j G5P2IX6scMZEr4giSk+UQUkLo8VwE2QbA0A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdeiuddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepvfgrkhgrshhhihcu ufgrkhgrmhhothhouceoohdqthgrkhgrshhhihesshgrkhgrmhhotggthhhirdhjpheqne cuggftrfgrthhtvghrnhepveeilefhudekffehkeffudduvedvfeduleelfeegieeljeeh jeeuvdeghfetvedvnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehoqdhtrghkrghshhhisehs rghkrghmohgttghhihdrjhhppdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpoh huthdprhgtphhtthhopehpvghrvgigsehpvghrvgigrdgtiidprhgtphhtthhopehmrdgr rhhmshgshiesghhmgidruggvpdhrtghpthhtoheprghlshgrqdguvghvvghlsegrlhhsrg dqphhrohhjvggtthdrohhrghdprhgtphhtthhopehtrghkrghsfihivgeskhgvrhhnvghl rdhorhhg X-ME-Proxy: Feedback-ID: ie8e14432:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 4 Sep 2025 09:18:09 -0400 (EDT) Date: Thu, 4 Sep 2025 22:18:07 +0900 From: Takashi Sakamoto To: Jaroslav Kysela Cc: "M. Armsby" , alsa-devel@alsa-project.org, Takashi Sakamoto Subject: Re: ALSAfirewire broken / Pipewire 90ms delay Message-ID: <20250904131807.GA209723@workstation.local> Mail-Followup-To: Jaroslav Kysela , "M. Armsby" , alsa-devel@alsa-project.org, Takashi Sakamoto References: <224C5A41-DCED-4FA2-BE82-898F257DA2E9@gmx.de> <20250724143813.GA23616@workstation.local> <48A27ABA-5EF6-400D-A47A-103C1A4ABC6D@gmx.de> <1B53DD0F-1D85-49EC-BA7F-970BE9AEF457@gmx.de> <20250903111519.GA76122@workstation.local> <3e07de0a-affa-4776-9172-83b2b071fbe8@perex.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e07de0a-affa-4776-9172-83b2b071fbe8@perex.cz> Message-ID-Hash: 2PIEVBJ2U2JAIOKOCKN2AOO5A3ORGJTX X-Message-ID-Hash: 2PIEVBJ2U2JAIOKOCKN2AOO5A3ORGJTX X-MailFrom: o-takashi@sakamocchi.jp 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: Hi, On Wed, Sep 03, 2025 at 02:19:59PM +0200, Jaroslav Kysela wrote: > On 03. 09. 25 13:15, Takashi Sakamoto wrote: > > Hi Jaroslav, > > > > On Wed, Sep 03, 2025 at 10:47:32AM +0200, Jaroslav Kysela wrote: > > > For Takashi Sakamoto: > > > > > > The hw_params constraints in the firewire driver should be improved based on > > > [1]. The drivers may also require the SNDRV_PCM_INFO_BATCH info flag. > > > > How it works in this case? > > I guess that the question is for the BATCH flag. It's just an information > that the stream queuing is not granular enough like for PCI cards and the > samples are queued in chunks to the hardware. Applications can handle the > queuing differently in this case. Hm. A packet can multiplex several Multi Bit Linear Audio (MBLA) data frames defined in IEC 61883-1/6 (e.g. 0, 6-8 frames per packet at 48.0 kHz sampling transmission rate) When considering the frame count reported by typical serial sound interface in embedded SoCs, this granularity is not particularly unusual, even if DMA transmission occurs between system buffer and the interface buffer. Since the ALSA PCM interface does not expose this granularity, it remains invisible to userspace applications, and application therefore cannot distinguish its origin. This is why these drivers does not report the BATCH flag[1]. Nevertheless, one likely reason might be that i programmed the IEC 61883-1/6 packet stream engine to recycle retired packet buffers as quickly as possible, using a "sequence replay" approach. This behaviour may appear as though it follow the concept of the BATCH flag. I plan to redesign both the engine and PCM operation implementations of each driver to address this point, as well as to add support for SNDRV_PCM_INFO_SYNC_APPLPTR to packetize in application processes. However, it is not yet the right time (I still have some items in Linux firewire stack itself). > See also proposed (and applied) change in [2]. Please, read [1] thread > referred in my previous e-mail to see the problematic buffer size > configurations for firewire drivers. In Linux FireWire subsystem, there is a size restriction on the context header within the.structure specific to isochronous context[2]. This software-side restriction determines the upper limit of the PCM buffer. The content of IEC 61883-1/6 CIP header is stored into this buffer, The frame count in each PCM period/buffer, as well as the total count itself, are governed by the computation of the number of headers fitting into the context header buffer[3]. The count differs by the design of target device. The design of protocol mentioned in the above appends more constraints[4]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=d360870a5bcf [2] https://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394.git/tree/drivers/firewire/ohci.c?h=v6.16#n3137 [3] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/firewire/amdtp-stream.c?h=v6.16#n227 [4] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/tree/sound/firewire/amdtp-stream.c?h=v6.16#n160 Regards Takashi Sakamoto