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
next prev parent 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