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

[Kai Vehmanen <kai.vehmanen@linux.intel.com>]

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