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 14:14, Jaroslav Kysela wrote:
> On 4/14/26 12:44, Péter Ujfalusi wrote:
> 
>>> 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:
> I don't think so. Actually, sound servers set relatively "big" period
> sizes and expect the lower transfer granularity.

yes, this is what they do.

> The "latency" request must come from application.

Fair point, although the PCM device could advertise that I'm 'jumpy' so
application can check how it will behave.

I also have hard time applying the term 'latency' on this as the aim is
not to introduce latency, but to increase power saving which do causes
increased latency by design.
I can increase latency easily without any power saving benefit by using
big buffer and still streaming constantly into it from ALSA buffer -
let's say for running *trendy-two-letter-word* algorithm on the audio.

I'm OK with latency of XYms with this stream does not imply that jumpy
DMA is also OK. Unless the two is tied by definition in documentation.

> If you read my last proposal, there are two new flags and one changes
> (clarifies) "period size" to be related to the expected (transfer)
> latency.

With my 'simplified' view this is also possible, but the driver tells
(via a flag in snd_pcm_hardware.info) the application that on the device
the period size will relate to jumpy-DMA, please check back how this
will affect you after you set you buffers.

> So, the current (inaccurate - driver specific) behavior won't
> change until application set this flag.

Sort of similar way how the SNDRV_PCM_INFO_NO_PERIOD_WAKEUP /
SNDRV_PCM_HW_PARAMS_NO_PERIOD_WAKEUP is implemented?

I guess an implicit flag from user space would be good so that if the
hw_params flag is not set by applications then the FIFO is either
disabled or the PCM will work with minimal buffers - like in SOF the
default PCM.

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

This is why I try to see this from a power or race to idle point of view.
It is sort of I'm OK to not touch data right on front of the hw_ptr
because I know that initially the DMA will move about this far and then
at every Zms it will move Zms ahead - which I can actually monitor via
the PCM delay.

> I just miss this handshake in your proposal and scratching my head why
> we cannot use period sizes for this, because (as explained) it was the
> base transfer block when the API was designed.

Yes, the handhsake was missing, let me think about this a bit more.

-- 
Péter