ASoC: SOF: ipc4-topology: Change DeepBuffer from static to dynamic mode by ujfalusi · Pull Request #5673 · thesofproject/linux

ujfalusi · 2026-02-19T09:41:16Z

Currently the DeepBuffer results static host DMA buffer and thus static
minimum ALSA period size which can be a limiting factor for user space.
DeepBuffer of static 100ms host DMA buffer can only be opened with at least
110ms ALSA period size, if for the same endpoint there is a need for
smaller (or larger) buffer then a new PCM device must be created with
different DeepBuffer configuration.
This does not scale in real life.

With Dynamic DeepBuffer the host DAM buffer size is calculated based on the
requested ALSA period size (with a headroom between the two) using the
DEEP_BUFFER token as a maximum limit for the host DMA buffer.
This way applications can use the same DeepBuffer enabled PCM for different
use cases and still benefit of the power saving of a bigger host DMA
buffer.
As an example, the DEEP_BUFFER in topology is set to 100ms (interpreted as
maximum size with this patch):
ALSA period time of 20ms will result 10ms host DMA Buffer
 - before the patch if 10ms host DMA buffer was desired, the minimum ALSA
   period size was 20ms
ALSA period size of 50ms will result 40ms host DMA buffer
 - before the patch if 40ms host DMA buffer was desired, the minimum ALSA
   period size was 50ms
ALSA period size of 110ms will result 100ms host DMA buffer
 - before the patch if 100ms host DMA buffer was desired, the minimum ALSA
   period size was 110ms
ALSA period size of 500ms will result 100ms host DMA buffer
 - Like before this patch: 500ms ALSA period would use 100ms host DMA
   buffer

The Dynamic DeepBuffer will give applications the means to choose between
lower latency (small host DMA buffer) or higher power save (big host DMA
buffer) with higher latency on the same device with topology providing a
meaningful upper limit of the buffer size.

lgirdwood · 2026-02-19T09:46:14Z

@naveen-manohar @udaymb pls review.

lgirdwood

LGTM @ujfalusi I assume the rule applies to both directions and works well with latency/position reporting granularity ? i.e. we dont need to update the granularity of position reporting coming from FW/driver ?

ujfalusi · 2026-02-19T10:31:24Z

LGTM @ujfalusi I assume the rule applies to both directions and works well with latency/position reporting granularity ? i.e. we dont need to update the granularity of position reporting coming from FW/driver ?

The position and delay reporting is not affected by the change, everything works as it used to work.

With Dynamic DeepBuffer the host DMA buffer size is calculated based on the requested ALSA period size (with a headroom between the two) using the DEEP_BUFFER token as a maximum limit for the host DMA buffer. This way applications can use the same DeepBuffer enabled PCM for different use cases and still benefit of the power saving of a bigger host DMA Kernel has been updated thesofproject/linux#5673 Signed-off-by: Uday M Bhat <uday.m.bhat@intel.com>

sound/soc/sof/ipc4-topology.c

lyakh · 2026-02-20T08:00:27Z

sound/soc/sof/ipc4-topology.c

+	if (deep_buffer_dma_ms)
+		dev_dbg(scomp->dev,
+			"%s, dma buffer%s: %u ms (max: %u) / %u bytes, ALSA period: %u / %u\n",
+			swidget->widget->name, deep_buffer_dma_ms ? " (using Deep Buffer)" : "",


you already know, that deep_buffer_dma_ms != 0

yes, just occurred to me as well ;)
but the string is already too long :(

lyakh · 2026-02-20T08:09:01Z

sound/soc/sof/intel/hda-pcm.c

 			SNDRV_PCM_HW_PARAM_PERIOD_TIME,
-			period_time * USEC_PER_MSEC,
+			spcm->stream[direction].dsp_min_burst_size_in_ms * USEC_PER_MSEC,
 			UINT_MAX);


just to double check - this is correct - using a "min" value to set a "max" constraint?

using the min value to set the min constraint, max is UINT_MAX, This is why I'm renaming the variable.

ujfalusi · 2026-02-20T10:18:40Z

Changes since v1:

fix typo in commit message (DAM -> DMA)
convert the helper function void and set the copier_data->gtw_cfg.dma_buffer_size within.
change how the dma buffer information is printed.

With Dynamic DeepBuffer the host DMA buffer size is calculated based on the requested ALSA period size (with a headroom between the two) using the DEEP_BUFFER token as a maximum limit for the host DMA buffer. This way applications can use the same DeepBuffer enabled PCM for different use cases and still benefit of the power saving of a bigger host DMA Kernel has been updated thesofproject/linux#5673 Signed-off-by: Uday M Bhat <uday.m.bhat@intel.com>

ujfalusi · 2026-02-27T11:06:12Z

Changes since v2:

fix hda-pcm constraint to apply 2x of min host DMA buffer size as minimum period size
Change how dynamic DB works:
under 20ms period size: hDMAb = period_time - 4ms (min host DMA size)
above 20ms period size: hDMAb = period_time - capped at DB max size
reasoning: the firmware switches to burst host DMA mode above 8ms hDMAb size with keeping 4ms of threshold, iow, it will trigger DMA when the hDMAb have less than 4ms data available. The 20ms switchover in kernel is safe enough.

ranj063

LGTM with some minor nits about a couple of typos

ranj063 · 2026-03-02T20:14:43Z

sound/soc/sof/ipc4-topology.c

+	 * Add headroom (the minimum size of the host DMA buffer) between host
+	 * DMA buffer and ALSA period size if the ALSA period is less than
+	 * SOF_IPC4_NO_DMA_BUFFER_HEADROOM_MS, otherwise equal the host DMA
+	 * buffer to ALSA period size, caped at the maximum DeepBuffer depth


typo capped

ranj063 · 2026-03-02T20:14:55Z

sound/soc/sof/ipc4-topology.h


+/*
+ * When the host DMA buffer size is larger than 8ms, the firmware switches from
+ * a constant fill mode to burst mode, keeping a 4ms threashold to trigger a


typo threshold

With Dynamic DeepBuffer the host DMA buffer size is calculated based on the requested ALSA period size (with a headroom between the two) using the DEEP_BUFFER token as a maximum limit for the host DMA buffer. This way applications can use the same DeepBuffer enabled PCM for different use cases and still benefit of the power saving of a bigger host DMA Kernel has been updated thesofproject/linux#5673 Signed-off-by: Uday M Bhat <uday.m.bhat@intel.com>

With Dynamic DeepBuffer the host DMA buffer size is calculated based on the requested ALSA period size (with a headroom between the two) using the DEEP_BUFFER token as a maximum limit for the host DMA buffer. This way applications can use the same DeepBuffer enabled PCM for different use cases and still benefit of the power saving of a bigger host DMA Kernel has been updated thesofproject/linux#5673 Signed-off-by: Uday M Bhat <uday.m.bhat@intel.com> (cherry picked from commit 9ce8671)

ujfalusi · 2026-03-04T06:40:31Z

Changes since v3:

typos corrected in comments

With Dynamic DeepBuffer the host DMA buffer size is calculated based on the requested ALSA period size (with a headroom between the two) using the DEEP_BUFFER token as a maximum limit for the host DMA buffer. This way applications can use the same DeepBuffer enabled PCM for different use cases and still benefit of the power saving of a bigger host DMA Kernel has been updated thesofproject/linux#5673 Signed-off-by: Uday M Bhat <uday.m.bhat@intel.com> (cherry picked from commit 9ce8671)

kv2019i

Code itself looks good (and this is a great improvement), but I have some issues with the naming and commentary. The calculations done are somewhat hairy to follow and I think it's important this is made as easy to follow as possible as potentially a lot of people really have to figure out the logic. I admit most (if not all) of the problematic naming predates this PR, but given you do more math on the numbers, the confusion comes more problematic thatn before. Please take a look at comments.

kv2019i · 2026-03-12T11:16:40Z

sound/soc/sof/ipc4-topology.c

+	if (swidget->id == snd_soc_dapm_aif_in)
+		host_period_bytes = copier_data->base_config.ibs;
+	else
+		host_period_bytes = copier_data->base_config.obs;


I find the "host_period_bytes" variable name quite confusing. The ALSA host side "period" is after all different than DSP's internal "period" (which is usually 1ms in wall clock time and not direclty tied to ALSA period size). I think to understand this, it would be good to add a comment on the assumption made here that 'copier ibs/obs is set match one "DSP period" of data'. The correct variable would then be "fw_period_bytes".

I'm really-really-really bad at this naming thing...

kv2019i · 2026-03-12T11:23:24Z

sound/soc/sof/ipc4-topology.c

+		host_period_bytes = copier_data->base_config.obs;
+
+	min_size = SOF_IPC4_MIN_DMA_BUFFER_SIZE * host_period_bytes;
+	no_headroom_mark = SOF_IPC4_NO_DMA_BUFFER_HEADROOM_MS * host_period_bytes;


The confusion has been in existing code, but now that you do more calculations, it is getting harder to ignore. Both SOF_IPC4_MIN_DMA_BUFFER_SIZE and SOF_IPC4_NO_DMA_BUFFER_HEADROOM_MS assume the DSP LL tick is 1ms. To be pedantic, these should be "bytes per DSP-period", so when you multiply with host_period_bytes/fw_period_bytes, the math makes sense.

The calculation assumes that a tick is fw_period_bytes long in bytes and yes, the _MS is an indication that a tick is 1ms long.

I think this is a standing assumption even if the DMA might move more data at once (when bursting).

My biggest issue is with the BUFFER_SIZE name. It comes from one of the messages which defines the "buffer size" in ms and not in bytes, afaik.

A comment to explain this?

kv2019i · 2026-03-12T11:31:09Z

sound/soc/sof/ipc4-topology.c

+		deep_buffer_dma_ms ? deep_buffer_dma_ms : SOF_IPC4_MIN_DMA_BUFFER_SIZE,
+		buffer_bytes, fe_period_bytes / host_period_bytes, fe_period_bytes);
+
+	copier_data->gtw_cfg.dma_buffer_size = buffer_bytes;


I also wonder about using "host buffer size" (e.g. in sof_ipc4_set_host_dma_buffer_size() function name here. In DSP world, we use "host DMA" and "DAI DMA" terms universally to distinguish when we are talking about data transfer towards Linux host, or when it's about DMAs used to transfer data to audio codec interfaces.

But this is in context of Linux kernel. Here we have two buffers, one in host DDR (the ALSA buffer DMA buffer) and one in DSP SRAM. What this function calculates is the size of the DSP SRAM buffer, and I'd argue calling this the "host buffer" in this context, is hard to follow.

Not a blocker. If this is used in enough places elsewhere in the driver, the damage is already done and we can just move on, but please consider if I'm alone with my confusion, or could naming be made easier to follow.

I see, but I will run out of columns on a 4k monitor if I go and exact-word name variables...
fw_host_dma_buffer_size, it is not a fw_dma_buffer as DAI side also have DMA buffer.

So I settled in the middle: ALSA buffer vs host DMA buffer.

as for the copier_data->gtw_cfg.dma_buffer_size, it is a message to the fw to configure the copier with that size of buffer.

But changing the function to sof_ipc4_set_fw_host_dma_buffer_size is a bit too much, it sets the dma_buffer_size for the host copier.

Any suggestions?

Currently the DeepBuffer results static host DMA buffer and thus static minimum ALSA period size which can be a limiting factor for user space. DeepBuffer of static 100ms host DMA buffer can only be opened with at least 110ms ALSA period size, if for the same endpoint there is a need for smaller (or larger) buffer then a new PCM device must be created with different DeepBuffer configuration. This does not scale in real life. With Dynamic DeepBuffer the host DMA buffer size is calculated based on the requested ALSA period size using the DEEP_BUFFER token as a maximum limit for the host DMA buffer. This way applications can use the same DeepBuffer enabled PCM for different use cases and still benefit of the power saving of a bigger host DMA buffer. As an example, the DEEP_BUFFER in topology is set to 100ms (interpreted as maximum size with this patch): ALSA period: 8 -> dma buffer: 4 ms ALSA period: 10 -> dma buffer: 6 ms ALSA period: 16 -> dma buffer: 12 ms ALSA period: 19 -> dma buffer: 15 ms ALSA period: 20 -> dma buffer: 20 ms ALSA period: 50 -> dma buffer: 50 ms ALSA period: 100 -> dma buffer: 100 ms ALSA period: 150 -> dma buffer: 100 ms ALSA period: 2000 -> dma buffer: 100 ms The Dynamic DeepBuffer will give applications the means to choose between lower latency (small host DMA buffer) or higher power save (big host DMA buffer) with higher latency on the same device with topology providing a meaningful upper limit of the buffer size. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

…st_size_in_ms The meaning of the variable has changed with he Dynamic DeepBuffer and it reflects the smallest burst that the host DMA does. This can be used to set the minimum period time constraint to avoid overshooting by the DMA burst. Change the name and update the related code in Intel hda_dsp_pcm_open() to reflect the revised meaning. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>

ujfalusi · 2026-03-12T14:00:05Z

Changes since v4:

rename the host_period_bytes to fw_period_bytes
comments updated in hope for better clarity.

ujfalusi requested review from naveen-manohar, singalsu and udaymb February 19, 2026 09:41

ujfalusi requested review from bardliao, dbaluta, kv2019i, lgirdwood, lyakh, plbossart and ranj063 as code owners February 19, 2026 09:41

lgirdwood reviewed Feb 19, 2026

View reviewed changes

ujfalusi mentioned this pull request Feb 19, 2026

ASoC: SOF: Initial support for IPC4 compress offload #5647

Draft

udaymb mentioned this pull request Feb 20, 2026

topology2: tplg-targets-sdca-generic: remove 10ms deep buffer dma buffer thesofproject/sof#10559

Merged

lyakh reviewed Feb 20, 2026

View reviewed changes

ujfalusi mentioned this pull request Feb 20, 2026

topology2: add support form compressed playback thesofproject/sof#10547

Merged

ujfalusi force-pushed the peter/sof/pr/dynamic_deepbuffer_ipc4 branch from 97366b1 to d53f6ea Compare February 20, 2026 10:17

udaymb approved these changes Feb 25, 2026

View reviewed changes

ujfalusi force-pushed the peter/sof/pr/dynamic_deepbuffer_ipc4 branch from d53f6ea to c4b7bfb Compare February 27, 2026 11:02

ranj063 previously approved these changes Mar 2, 2026

View reviewed changes

ujfalusi dismissed ranj063’s stale review via f1b4091 March 4, 2026 06:39

ujfalusi force-pushed the peter/sof/pr/dynamic_deepbuffer_ipc4 branch from c4b7bfb to f1b4091 Compare March 4, 2026 06:39

ranj063 previously approved these changes Mar 4, 2026

View reviewed changes

kv2019i requested changes Mar 12, 2026

View reviewed changes

ujfalusi added 2 commits March 12, 2026 15:58

ujfalusi dismissed ranj063’s stale review via 373fd82 March 12, 2026 13:58

ujfalusi force-pushed the peter/sof/pr/dynamic_deepbuffer_ipc4 branch from f1b4091 to 373fd82 Compare March 12, 2026 13:58

Conversation

ujfalusi commented Feb 19, 2026

Uh oh!

lgirdwood commented Feb 19, 2026

Uh oh!

lgirdwood left a comment

Choose a reason for hiding this comment

Uh oh!

ujfalusi commented Feb 19, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ujfalusi commented Feb 20, 2026

Uh oh!

ujfalusi commented Feb 27, 2026

Uh oh!

ranj063 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ujfalusi commented Mar 4, 2026

Uh oh!

kv2019i left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ujfalusi commented Mar 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants