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:26 UTC|newest]
Thread overview: 32+ 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-04-14 10:44 ` Péter Ujfalusi
2026-04-14 11:14 ` Jaroslav Kysela
2026-04-14 13:47 ` Péter Ujfalusi
2026-04-14 17:23 ` Jaroslav Kysela
2026-04-22 14:19 ` Péter Ujfalusi
2026-04-23 5:05 ` Péter Ujfalusi
2026-04-30 15:21 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.