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

["Péter Ujfalusi" <peter.ujfalusi@linux.intel.com>]

On 31/03/2026 09:36, Takashi Iwai wrote:
>> We came to the same conclusion with Jaroslav, and the plan is to
>> introduce two new parameter in hw_params:
>> init_chunk and step_chunk, both in frames.
>> init_chunk - is the size of the hw_ptr jump right when the start happens
>> step_chunk - is the runtime jump size which happens every step_chunk time.
>>
>> for example:
>> init_chunk = 100ms
>> step_chunk = 1ms
>> hw_ptr moves 100ms on start (pointing to 101ms), after 1ms of time the
>> hw_ptr will move 1ms ahead to 102ms, in another 1ms it again moves 1ms
>> to 103ms...
>>
>> init_chunk = 100ms
>> step_chunk = 96ms
>> hw_ptr moves 100ms on start (pointing to 101ms), after 96ms of time the
>> hw_ptr will move 96ms ahead to 197ms, in another 96ms it again moves 1ms
>> to 293ms...
> 
> In the second example, where does 1ms offset comes from?
>   hw_ptr moves 100ms on start (pointing to 101ms)

The DMA moved 100ms, so the hw_ptr is now pointing to the data after it,
which is the start of the 101th ms.

> I thought that this 1ms is the step_chunk size in the first example...
> 
>> Note, the first is theoretical, with SOF 1ms step is used only with
>> 'small' DSP side buffer:
>>
>> init_chunk = 4ms
>> step_chunk = 1ms
>> hw_ptr moves 4ms on start (pointing to 5ms), after 1ms of time the
>> hw_ptr will move 1ms ahead to 6ms, in another 1ms it again moves 1ms to
>> 7ms...
> 
> So, init_chunk is the size to be filled up at the start, something
> similar like sw_params.start_threshold, but it's rather a hardware
> requirement.

Yes and no,
yes since there must be init_chunk amount be in the buffer to avoid
immediate xrun.
no, because if even if init_chunk amount is prepared, the application
must provide step_chunk data within step_chunk time, failure to do so
will also result xrun.
init_chunk=100ms
application needs ~5ms to produce new data after start
step_chunk=1ms
in 5ms the when the application is able to produce new data, the hw_ptr
will be 106ms, so it must have provided at least this amount on start.

step_chunk=1ms
in 5ms the when the application is able to produce new data, the hw_ptr
will be 101ms, application can safely rewrite t he data at that
location, it is safe to provide only 100ms of data for start.

> And step_chunk is essentially the hw_ptr granularity?

In essence yes, we can report sub step_chunk position, but in practice
the DMA burst is fast.

>> I'm not sure if we want these to be snd_pcm_uframes_t types in
>> snd_pcm_hw_params or should be u32 simplify the shrinking of reserved..
>>
>> -       unsigned char reserved[48];
>> +       snd_pcm_uframes_t init_chunk;	/* in frames */
>> +       snd_pcm_uframes_t step_chunk;	/* in frames */
>> +       unsigned char reserved[48 - 2 * sizeof(snd_pcm_uframes_t)];
>>
>> with u32 we can simply change the reserved size to 40, which is anyways
>> going to be the case for the snd_pcm_hw_params32{}
> 
> In my idea, it may be configurable, hence it belongs to interval, so
> it's two in ires[9] for the reserved intervals.

I see.

>>> if a device allows a different queue size, it should be configurable
>>> via hw_params.
>>
>> I'm not sure if I follow this statement. the fifo_size is a driver to
>> user space information, driver fills it and user space ignores it ;) - I
>> cannot find any evidence of it's use.
> 
> If a chip has a similar constraint but the init and step sizes are
> adjustable, they should be configurable via hw_params procedure --
> that's my point.

The fifo_size is driver to application information, it is set by the driver.

>> The init_chunk, step_chunk would be similar, the driver sets it and user
>> space would use it.
>>
>> In SOF this will be dynamic and it will depend on the period size:
>> https://github.com/thesofproject/linux/pull/5673/commits/18f3ba5e42212d77019d79ec09b7057a7703d361
> 
> Well, so even in your case, the driver can implement the hw_constraint
> for coupling those numbers, too.  Then application may choose the
> init_chunk or step_chunk, which restricts the period size
> automatically.

We would also need a capability flag to say that this is supported on
the PCM device, right?
But, I see, the kernel places min/max or even step constraint on the
init_chunk and step_chunk, but the step_chunk must be also constrained
and refined in core in correlation with the init_chunk.
Limiting the period size is something I'm not sure about, probably the
minimum size can be limited, but how to calculate it?
The upper constraint is problematic when for example you want some
buffering (~40ms) but still want to have bigger period sizes because you
want bigger buffer and the number of periods are limited already by
hardware.

> If application doesn't choose those, the hw_params
> engine will choose depending on the period size, and application can
> see the values after hw_params call.

Hm, I cannot constrain the period size in open when I don't know if the
user will set the init/step_chunk and if they set it then somehow I need
to use that, but if not set then use the dynamic DB size calculation and
set the interval accordingly?

I guess some of this work must be done by the core, some by the driver..

-- 
Péter