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

Jaroslav Kysela
2026-04-14T11:14:41Z

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. The "latency" request must come
from application.

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.
So, the current (inaccurate - driver specific) behavior won't change until
application set this flag. 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.

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.

Jaroslav

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