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

Kai Vehmanen
2026-03-31T10:42:48Z

Hey,

On Tue, 31 Mar 2026, Jaroslav Kysela wrote:

> So, perhaps, the only flag may be added notifying that the (first) minimal
> period is processed immediately after start. It's also common situation for
> other drivers with double buffering in the driver like USB, maybe FireWire,
> right ? Note that this flag won't be the BATCH flag. Or we can just add a
> field notifying how many minimal periods are queued at start to be more
> universal (apparently SOF requires this, because the initial chunk of queued
> samples is bigger then the later chunks - so the first transfer will go over
> more periods).
>
> We may discuss if small periods are efficient. We have already mechanism to
> disable period events (SNDRV_PCM_HW_PARAMS_NO_PERIOD_WAKEUP) and drivers don't
> do usually deep buffering, so they program DMA transfers with smaller (or
> equal) chunks than period size.
>
> It seems to me that we are trying to design another layer on top of the
> current just to satisfy the improper current PCM API use.

btw, I think this is a bit of a chicken and egg problem. Hardware may have
deep buffering capability, but it's difficult to enable via ALSA without
breaking applications with current interfaces (and how they are used).
There could be more drivers that enable deep buffering if the semantics
were clear.

E.g. with SOF firmware, the buffering behaviour is completely
programmable. E.g. we could have a 100ms buffer between main CPU and the
DSP and still report accurate delay with snd_pcm_delay(). In most cases
the FW support is there anyways and one could enable this just by
modifying the DSP topology file (which is basicly an alsaconf file). The
hw_ptr will move in bursts, and will move faster-than-realtime at start.
And it's important to note, to maximize power benefits, the exact size and
timing of the bursts may be driven by what else is going on in the system.
The audio DSP of course knows what is the maximum size of a burst (as the
DSP needs to have local memory to receive the transfer), but we can't
guarantee the acual burst (as seen as hw_ptr movement) is always of the
same size.

We do already honor period size configuration set by applications and SOF
never allows DMA bursts to exceed period size.

But once we increase the buffer size beyond a few milliseconds,
applications start to break and we see the interpretation of the ALSA
period semantics becomes less and less clear.

PS The DSP code that decides on DMA reloads in SOF (this is called every
1ms, hd->dma_buffer_size is buffer towards host, this can be tens of
msecs):
https://github.com/thesofproject/sof/blob/main/src/audio/host-zephyr.c#L570
.. this is common code in SOF, not specific to any one vendor.

Br, Kai