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

Jaroslav Kysela
2026-03-24T15:48:22Z

On 3/24/26 11:51, Péter Ujfalusi wrote:

>> But if we agree on other name like 'burst_size' or 'batch_size', I'll be
>> fine with it, too.
>
> I think neither of these are right, unless we substitute them with a
> variable which tells the size of the FIFO in hardware that is going to
> be filled.
> max_hw_ptr_burst_size or max_dma_burst_size or max_burst_size - in frames?

I missed the 100ms + 1ms case (it was a bit hidden in the examples). Looking
to this again, I think that the terminology should be more abstracted. The DMA
word is not appropriate in this contents. Even the burst word is not so good.
Also, applications do not work with hw_ptr, but with the avail / delay values
(calculated from the head [hw_ptr] /tail [appl_ptr] - playback).

I think that we both mean similar thing, but the question is how to define the
right API for it.

Basically, for playback this value should be the "minimal fill" recommendation
to avoid underruns. So for your examples, it should be 101ms or 196ms (but in
samples) right ?

If we look to other direction (capture), it may describe the "maximal sample
block" which will be put to the audio buffer (hw_ptr change).

So, perhaps, the xfer_latency name may be used (value should be in samples)?
Applications should not go bellow this value.

Jaroslav

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