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 14/04/2026 20:23, Jaroslav Kysela wrote:
> [appologize Péter - I forgot to include others, so duplicating for you]

Sorry for the delay, I was pulled into something unrelated...

> On 4/14/26 15:47, Péter Ujfalusi wrote:
> 
>>> This extension allows us to do
>>> the full "refine" (handshake) between application and kernel to settle
>>> the transfer details with the slightly updated framework. Also, this
>>> flag will activate init_periods and step_periods fields. Basically, the
>>> app will set the maximal acceptable period size (expected latency = 2 *
>>> period size) and the driver will return first biggest period size
>>> depending on driver constraints (initial periods will be included - in
>>> this case the period size must be lowered to maintain the requested
>>> latency). It's the complete handshake.
>>
>> My main problem with this is that I cannot reply to application which
>> say that I can accept up to XYms latency.
> 
> You can reply the maximal period size (thus maximal accepted latency).
> Basically, I think that the minimal and maximal period size boundaries
> will be
> a hint for apps to determine the lowest and highest available latencies.

Right, but how this differs from driver setting SNDRV_PCM_INFO_JUMPY_DMA
to say that it can have jumpyDMA and application telling that I know how
to handle this with a SNDRV_PCM_HW_PARAMS_JUMPY_DMA flag and returning
the chunk_init and step to application which is based on the period size?

>> I don't know the latency in here, it depends on the DSP topology that
>> has been loaded, what I can know is how the host side hw_ptr will behave.
> 
> I don't understand. Who else than the driver can know the latency
> constraints?
> Driver loads the topologies, doesn't ?

Sure, but the driver can just guess this. What if we have a module in
DSP in path which adds delay and is configurable (a delay modue or
reverb or something else)? The delay / latency jumpiness of the DMA is
while related, they are different things. The Jumpy part is just one
part of things.
Also to note that during open, hw_params we don't necessarily know the
full path and thus cannot calculate the non jumpyDMA related latency.
Not to mention that the codec might add latency, so the host (hw_ptr)
side cannot reliably decide what it should do with it's part of the
'latency'.

>> Sure, that translates to a 'latency' It will add maximum of FIFO size
>> latency , but this FIFO size is not equal to the initial burst size in
>> some cases, if the FIFO size is small then we will overshoot with hw_ptr.
> 
> Yes, I proposed that app will ask for latency using period size, but driver
> may reduce period size according the initial burst, like:
> 
> Application expects 50ms latency, so it sets period size for 25ms. But
> driver supports only 30ms initial burst and 5ms transfer granularity, so it will
> reply with 10ms period size, 3 initial periods (3 * 10 = 30) and 1 step
> period (2 * 1 * 10 = 20). The initial burst must be handled separately, because
> apps should know which "block" is being transferred, thus we need 2 periods at
> minimum to ensure that (one active, second for the buffering) for the
> standard streaming.

Hrm, so this is a driver scoped refine, right? Based on the requested
period size and a flag (SNDRV_PCM_HW_PARAMS_LATENCY_AWARE?) the driver
refines the period size based on it's jumpyDMA capabilities?

But in this example the application will have no knowledge still how the
DMA will move, the DMA will initially move 30ms and after that, every
5ms it moves 5ms, so the driver should be refining to 5ms period size, 6
initial periods and 1 period step, no.

Or with my favorite examples:
4ms initial burst w/ 1ms steps will refine to 1ms periods, 4 init and 1
step.
100ms initial burst w/ 96ms steps will refine to... I'm not sure, and
same for
40ms initial burst w/ 36ms steps.

And in you example of application prepared for 50ms 'latency' and asking
fro 25ms period size, how that would refine in case the driver/hardware
is flexible?
The step and initial burst might be just few ms different based on how
the arch is working, the diff usually is the wake-up latency to do the
burst from an idle system and this might depend on the depth of sleep as
well and the depth is not a fixed one, other peripherals can affect it
like blanked display so eGPU is not fetching from DDR for example.

> If the driver does not allow to set the exact specified latency, it should
> return the first lower latency setup.
> 
> For "full" buffering, the app may ask for the maximal (or very large)
> period
> size. In this case, the driver can optimize the period setup in the
> right way.
> And it can end with the deep buffer.

I think this deeper buffering should be only allowed or to be more
precise, can work if application is using the NO_PERIOD_WAKE (+
additional flag that it knows about the jumpyDMA?), it is hard or even
impossible in some cases to align both init and step chunks to period size.

> 
>                     Jaroslav
> 

-- 
Péter