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

Jaroslav Kysela
2026-04-14T17:23:58Z

[appologize Péter - I forgot to include others, so duplicating for you]

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.

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

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.

Jaroslav

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