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

Jaroslav Kysela
2026-04-07T13:51:32Z

On 4/7/26 13:59, Péter Ujfalusi wrote:

>> We need definitely a handshake (app<->kernel) for this, but the question
>> is, if just going back to honor the period sizes properly from the user
>> space applications is a right way to go or not. IMHO it may be just a
>> clarification for the current mechanism.
>>
>> In any case we need those extensions:
>>
>> Kernel -> user space:
>>
>> - give the initial transfer chunk size to user space
>> - give the next (step) transfer chunk size to user space
>>
>> 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.

>> 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.

>> User space -> kernel:
>>
>> - notification that the code honors period sizes + initial periods and
>> uses period size to ask kernel for requested latency (keeping the
>> current behavior for older binaries; and to allow drivers to do optimal
>> setup)
>> - request for low hw_ptr granularity (to use e.g. deep buffers) -
>> basically okay, we don't care, the "BATCH" transfer mode with whole
>> periods is okay
>>
>> Example (with the "honor period size" handshake activated):
>>
>> 20ms latency goal, 4ms hw transfers, 12ms initial hw buffer
>>
>> -> set period size to 10ms or less
>>      # 2 periods must be filled to avoid an initial xrun
>> -> set buffer size to 30ms or more
>> <- get 8 periods x 4ms
>> <- 3 initial periods (3*4ms = 12ms)
>>
>> suggested initial fill = 12ms + 2 * 4ms ; 20ms total
>>
>> The driver (constraints setup) should take account the initial periods
>> in this case.
>
> 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.

> 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
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?

> 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. The interface should be universal. This flag is just to not
inform user space that the period was processed. Dot.

> 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. How you would like to
handle this in an universal way?

Jaroslav

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