public inbox for linux-sound@vger.kernel.org
 help / color / mirror / Atom feed
From: "Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>
To: Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	Mark Brown <broonie@kernel.org>,
	Liam Girdwood <liam.r.girdwood@linux.intel.com>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>,
	"linux-sound@vger.kernel.org" <linux-sound@vger.kernel.org>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	arun@asymptotic.io, wim.taymans@gmail.com
Subject: Re: (re)use and (re)definition of snd_pcm_hw_params->fifo_size for 'jumpy DMA'
Date: Tue, 24 Mar 2026 15:25:55 +0200	[thread overview]
Message-ID: <fa31bed8-7446-4b83-b234-81f3cbfe3450@linux.intel.com> (raw)
In-Reply-To: <6b129498-f130-44a0-a679-6fa1c639046e@linux.intel.com>



On 24/03/2026 12:51, Péter Ujfalusi wrote:
> The question is: is it enough to only have single value exposed or do we
> need/want add all small variations of this to be exposed?
> I would think that a single dma_fifo_size should be OK and apps should
> prepare for the crawling DMA case.
> 
>> But if we agree on other name like 'burst_size' or 'batch_size', I'll be
>> fine with it, too.
> 
> I think neither of these are right, unless we substitute them with a
> variable which tells the size of the FIFO in hardware that is going to
> be filled.
> max_hw_ptr_burst_size or max_dma_burst_size or max_burst_size - in frames?

something like this in kernel and then we need alsa-lib update and then we can introduce the use in pipewire?

diff --git a/include/uapi/sound/asound.h b/include/uapi/sound/asound.h
index d3ce75ba938a..3a1872b3e701 100644
--- a/include/uapi/sound/asound.h
+++ b/include/uapi/sound/asound.h
@@ -421,7 +421,8 @@ struct snd_pcm_hw_params {
 	unsigned int rate_den;		/* R: rate denominator */
 	snd_pcm_uframes_t fifo_size;	/* R: chip FIFO size in frames */
 	unsigned char sync[16];		/* R: synchronization ID (perfect sync - one clock source) */
-	unsigned char reserved[48];	/* reserved for future */
+	snd_pcm_uframes_t max_dma_burst_size;	/* R: maximum DMA burst size in frames */
+	unsigned char reserved[48 - sizeof(snd_pcm_uframes_t)];	/* reserved for future */
 };
 
 enum {
diff --git a/sound/core/pcm_compat.c b/sound/core/pcm_compat.c
index e71f393d3b01..462588f3527b 100644
--- a/sound/core/pcm_compat.c
+++ b/sound/core/pcm_compat.c
@@ -64,7 +64,9 @@ struct snd_pcm_hw_params32 {
 	u32 rate_num;
 	u32 rate_den;
 	u32 fifo_size;
-	unsigned char reserved[64];
+	unsigned char sync[16];
+	u32 max_dma_burst_size;
+	unsigned char reserved[44];
 };
 
 struct snd_pcm_sw_params32 {
@@ -247,9 +249,11 @@ static int snd_pcm_ioctl_hw_params_compat(struct snd_pcm_substream *substream,
 	if (!data)
 		return -ENOMEM;
 
-	/* only fifo_size (RO from userspace) is different, so just copy all */
+	/* copy common members and fix up 32-bit uframe fields explicitly */
 	if (copy_from_user(data, data32, sizeof(*data32)))
 		return -EFAULT;
+	data->fifo_size = data32->fifo_size;
+	data->max_dma_burst_size = data32->max_dma_burst_size;
 
 	if (refine) {
 		err = snd_pcm_hw_refine(substream, data);
@@ -262,7 +266,8 @@ static int snd_pcm_ioctl_hw_params_compat(struct snd_pcm_substream *substream,
 	if (err < 0)
 		return err;
 	if (copy_to_user(data32, data, sizeof(*data32)) ||
-	    put_user(data->fifo_size, &data32->fifo_size))
+	    put_user(data->fifo_size, &data32->fifo_size) ||
+	    put_user(data->max_dma_burst_size, &data32->max_dma_burst_size))
 		return -EFAULT;
 
 	if (! refine) {


-- 
Péter


  reply	other threads:[~2026-03-24 13:25 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-23 13:34 (re)use and (re)definition of snd_pcm_hw_params->fifo_size for 'jumpy DMA' Péter Ujfalusi
2026-03-23 14:54 ` Jaroslav Kysela
2026-03-23 16:16   ` Péter Ujfalusi
2026-03-24  8:58     ` Jaroslav Kysela
2026-03-24 10:51       ` Péter Ujfalusi
2026-03-24 13:25         ` Péter Ujfalusi [this message]
2026-03-24 15:48         ` Jaroslav Kysela
2026-03-25 13:28           ` Péter Ujfalusi
2026-03-25 14:08             ` Jaroslav Kysela
2026-03-26 12:04               ` Péter Ujfalusi
2026-03-24  7:12 ` Péter Ujfalusi
2026-03-30 14:27 ` Takashi Iwai
2026-03-30 15:15   ` Péter Ujfalusi
2026-03-30 16:39     ` Takashi Iwai
2026-03-31  6:00       ` Péter Ujfalusi
2026-03-31  6:36         ` Takashi Iwai
2026-03-31  9:29           ` Jaroslav Kysela
2026-03-31 10:42             ` Kai Vehmanen
2026-03-31 10:56             ` Péter Ujfalusi
2026-03-31 12:00               ` Jaroslav Kysela
2026-03-31 14:09                 ` Péter Ujfalusi
2026-04-02 12:01                   ` Jaroslav Kysela
2026-04-07 11:59                     ` Péter Ujfalusi
2026-04-07 13:50                       ` Jaroslav Kysela
2026-03-31 11:19           ` Péter Ujfalusi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fa31bed8-7446-4b83-b234-81f3cbfe3450@linux.intel.com \
    --to=peter.ujfalusi@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=arun@asymptotic.io \
    --cc=broonie@kernel.org \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.com \
    --cc=wim.taymans@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox