Re: (re)use and (re)definition of snd_pcm_hw_params->fifo_size for 'jumpy DMA'

Jaroslav Kysela
2026-03-24T08:58:18Z

On 3/23/26 17:16, Péter Ujfalusi wrote:
>
>
> On 23/03/2026 16:54, Jaroslav Kysela wrote:
>>> Or should we add a new member (carved out from the reserved section of
>>> hw_params struct) specifically for this purpose, like dma_burst_size,
>>> which likely going to be equal to fifo_size if both is filled by the
>>> driver.
>>
>> I would not change the fifo_size definition at this moment. It's not
>> directly related to the sample transfers. This value just describes the
>> additional latency for streaming.
>
> Aren't we have the delay reported for this reason, which is actually in
> use by user space?

Yes, this field was defined before the final delay reporting. It describes the
static FIFOs in hardware. But it was not defined to be related to the hw_ptr
granularity (transfers). SOF may set this value to indicate fixed latencies
caused by double buffering, too.

>> The new member seems like a good way to go with more universal name like
>> 'chunk_size' (in frames) defining the transfer granularity information
>> for the PCM buffer I/O.
>
> right, but (I think these are the main issues that blocked any progress
> on this) this is not really about the chunk_size, it is telling user
> space what is the safe distance from hw_ptr to modify samples without
> the DMA jumping over the area.

It depends on the view and definition. From the hardware view, the
'chunk_size' may be defined as the maximal block transfer from (or to) the
audio buffer (describing the hw_ptr granularity). So applications will be
notified, that filling buffer lower than 'chunk_size' may introduce underruns.
It covers also the initial transfer (when hw_ptr moves immediately to
'chunk_size').

But if we agree on other name like 'burst_size' or 'batch_size', I'll be fine
with it, too.

Jaroslav

--
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.