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 07/04/2026 16:50, Jaroslav Kysela wrote:
>>> The minimal requirement for the playback data at start would be:
>>>
>>>      'init_chunk + (2 * step_chunk)'
>>>
>>> Note that init_chunk may be zero (legacy PCI HW).
>>
>> and step_chunk as well.
>
> step_chunk should start from one sample. But there are chunks (bursts)
> even for PCI devices, although very small.

What I meant is that drivers might report 0 for both when they don't
have this quirk in operation - and existing drivers.

>>> In my proposal, step_chunk == period_size and init_chunk will be
>>> provided using additional value in hw_params (as count of initial
>>> periods).
>>
>> I don't think this would work without breaking user space. Locking the
>> period size to be the size of a step_chunk?
>> In SOF the default PCM device have 1ms step_chunk and it can have
>> maximum of 256 periods (HDA BDLE constraint).
>
> The drivers can use period size in multiples of base transfer (step)
chunk.

They could if we lock the chunk_step as static, but if it is adapting to
the period size then we cannot.
the hardware have practical limit of 100ms maximum FIFO size.
"low latency' user will request 5ms period size and get 5ms FIFO size
period size 50ms will result 50ms FIFO size
period size 100ms will result 100ms FIFO size
period size 150ms will result 100ms FIFO size (practical limit of HW)
period size 300ms will result 100ms FIFO size (practical limit of HW)

User space asks for a period size and the driver reports back the chunk
init and size that the period size will translate to.

>> You cannot set a constraint after the hw_params has been set, that is
>> reverse of how things work, no?
>
> I expect to design new constraint describing the "base step chunk" and
> "initial chunk" in samples. Thus the refine mechanism will allow to
> settle period size based on this.

Some hardware have fixed setup, they can tell what the chunk init/size
is, it is constant, some (what I try to do for SOF) can adapt the chunk
configuration based on how userspace asks for the period_size.

On the other hand: there might be a use case when application wants
certain chunk size - jumpiness - while using 'detached' period size,
like 40ms chunks and 100ms periods (or 120ms if we want chunk multiple).
This is another type of config, but I would leave it for later and have
either the fixed chunk hardware and the adaptive supported.

>> Also the original issue that initiated the thread was that we had a
>> fixed 96ms hw transfer with 100ms FIFO coming as a fixed preset.
>> This caught application wanting to have 10/20/30/40/50ms of period size
>> on guard...
>
> 100ms init = 25 periods / 96ms step = 24 periods with period size 4ms.
> This means that we need
>
> 1) add step fill (in periods) like for init fill returned from driver
to app

but this will break existing applications, they don't know that they
need to provide 24 periods data.

> 2) or the driver (if possible) should prefer that init chunk is in
> multiple of step chunk - it's hw related restriction or just buffer size
> judgement from the developer POV for SOF?

I think this can be doable for SOF, if the FIFO / init_chunk is 'small'
we can make it about double of the step_chunk.
However these are not written in stone, the step_chunk for example might
fluctuate depending on system latencies for DSP wakeup.

>> The issue is different from hardware/kernel and user space pow.
>> - hardware
>> [A] it has no buffering or really minimal (few frames to keep the bus
>> fed)
>> [B] have fixed size FIFO with fixed sized bursting equal to the FIFO
>> size - relatively large FIFO
>> [C] have fixed size FIFO with different initial and runtime bursts
>> [D] have configurable FIFO and the the relation between initial and
>> runtime burst can fall into [B] or [C] depending on FIFO size, the FIFO
>> is scaling with the period size (to some limit in most cases)
>>
>> - applications
>> [1] uses ALSA period as processing unit
>> [2] uses NO_PERIOD_WAKEUP and ignores period size as processing unit.
>
> I'm also trying to resolve the deep buffer issue. And we should not use
> NO_PERIOD_WAKEUP as hint that applications don't do better transfer
> granularity IMHO.

I agree, on the other hand the NO_PERIOD_WAKEUP is added precisely for
this purpose, to detach applications from ALSA period based scheduling.

> The interface should be universal. This flag is just
> to not inform user space that the period was processed. Dot.

Sure, applications can leave out this flag and still just NOP on period
elapsed.

>> I think the two new parameter for init_chunk and step_chunk within
>> hw_params returned from driver to user space  should cover this well.
>
> My idea was just to reuse the current mechanism to settle transfer
> chunks, so applications can give advice, how the PCM buffer will be used
> (based on the period size and the granularity flag). See my proposal.

Some hardware cannot negotiate the size of FIFO, thus the init and step
chunk, some might be able to do so.
These ask for different solution.
If it is fixed then what drivers are already doing is fine, they set
constraint on period size to force applications, but applications still
have no way of knowing that the DMA is jumpy. This only works with no
frills applications, sound servers are not in this category.

> How you would like to handle this in an universal way?

I think both could be handled by driver provided init_chunk and
step_chunk value:
1. in open the fixed FIFO hardware sets constraint for period size, the
dynamic one can set for the minimum size as well.
2. application asks for buffer configuration, refining narrows it down
and settles.
3. driver fills in the init and step chunk info - fixed uses the fixed
numbers, dynamic uses the calculated one based on period size or
something else.
4a. application checks the init and step chunk and decides on strategy
4b. legacy applications will work as they work atm

Then we can figure out if there is a need for detaching the chunk
configuration from period size with a new value where applications can
ask for specific chunk setup with unmatched period size (small chunks
with bigger period sizes, big chunks with smaller period sizes).

It would be great to hear from PW guys on this as they would be the
primary users at first...

-- 
Péter