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

[Jaroslav Kysela <perex@perex.cz>]

On 3/25/26 14:28, Péter Ujfalusi wrote:

> Looking at the PW code (spa/plugins/alsa/alsa-pcm.c) and I sort of
> started to appreciate the 'headroom' term.
> 
> I disagree that this is not about DMA or about burst since it is
> precisely about that. It can be viewed as 'latency' but the latency is
> reported via the delay and the delay fluctuates over time based on how
> the DSP FIFO drains and fills.

My point was that we should not use those terms for the structure members, 
because it's standard prefill / data fetch (put) granularity issue. DMA is 
just the concrete use. Describing both parameters seem like the best idea.

> PW then probably can use these:
> state->start_delay = hw_buffer_size;
> state->headroom = hw_buffer_refill_step_size

We don't use head/tail in the buffer variables for ALSA API. The headroom can 
be named just 'update_granularity' or 'update_step' or so. Also, start delay 
is not correct, too. Maybe 'prefill' or 'init_fill' says all. Or we can 
eventually try to be more consistent and use 'init_chunk' and 'step_chunk' to 
notify applications about the data transfer characteristics from the other 
(hw) side of the audio buffer. The chunk word is not used actually in the ALSA 
API, so developers should not mix that with other things like fifo or period.

> and on start/xrun it might need to provide
> state->start_delay + max(state->start_delay, state->headroom)
> or to the distance that it is planning to wake up.

It will end with 2 * prefill for your examples, because start_delay > 
headroom. It should be just prefill + step.

Also, it seems that in SOF case, the queued "prefill" sample block is 
mandatory for internal processing, otherwise xrun will happen, or no ?

				Jaroslav

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