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

[Takashi Iwai <tiwai@suse.de>]

On Tue, 31 Mar 2026 08:00:56 +0200,
Péter Ujfalusi wrote:
> 
> 
> 
> On 30/03/2026 19:39, Takashi Iwai wrote:
> > OK, then I'd say that the existing fifo_size doesn't fit fully for
> > this kind of stuff.  e.g.
> 
> We came to the same conclusion with Jaroslav, and the plan is to
> introduce two new parameter in hw_params:
> init_chunk and step_chunk, both in frames.
> init_chunk - is the size of the hw_ptr jump right when the start happens
> step_chunk - is the runtime jump size which happens every step_chunk time.
> 
> for example:
> init_chunk = 100ms
> step_chunk = 1ms
> hw_ptr moves 100ms on start (pointing to 101ms), after 1ms of time the
> hw_ptr will move 1ms ahead to 102ms, in another 1ms it again moves 1ms
> to 103ms...
> 
> init_chunk = 100ms
> step_chunk = 96ms
> hw_ptr moves 100ms on start (pointing to 101ms), after 96ms of time the
> hw_ptr will move 96ms ahead to 197ms, in another 96ms it again moves 1ms
> to 293ms...

In the second example, where does 1ms offset comes from?
  hw_ptr moves 100ms on start (pointing to 101ms)

I thought that this 1ms is the step_chunk size in the first example...

> Note, the first is theoretical, with SOF 1ms step is used only with
> 'small' DSP side buffer:
> 
> init_chunk = 4ms
> step_chunk = 1ms
> hw_ptr moves 4ms on start (pointing to 5ms), after 1ms of time the
> hw_ptr will move 1ms ahead to 6ms, in another 1ms it again moves 1ms to
> 7ms...

So, init_chunk is the size to be filled up at the start, something
similar like sw_params.start_threshold, but it's rather a hardware
requirement.

And step_chunk is essentially the hw_ptr granularity?

> I'm not sure if we want these to be snd_pcm_uframes_t types in
> snd_pcm_hw_params or should be u32 simplify the shrinking of reserved..
> 
> -       unsigned char reserved[48];
> +       snd_pcm_uframes_t init_chunk;	/* in frames */
> +       snd_pcm_uframes_t step_chunk;	/* in frames */
> +       unsigned char reserved[48 - 2 * sizeof(snd_pcm_uframes_t)];
> 
> with u32 we can simply change the reserved size to 40, which is anyways
> going to be the case for the snd_pcm_hw_params32{}

In my idea, it may be configurable, hence it belongs to interval, so
it's two in ires[9] for the reserved intervals.

> > if a device allows a different queue size, it should be configurable
> > via hw_params.
> 
> I'm not sure if I follow this statement. the fifo_size is a driver to
> user space information, driver fills it and user space ignores it ;) - I
> cannot find any evidence of it's use.

If a chip has a similar constraint but the init and step sizes are
adjustable, they should be configurable via hw_params procedure --
that's my point.

> The init_chunk, step_chunk would be similar, the driver sets it and user
> space would use it.
> 
> In SOF this will be dynamic and it will depend on the period size:
> https://github.com/thesofproject/linux/pull/5673/commits/18f3ba5e42212d77019d79ec09b7057a7703d361

Well, so even in your case, the driver can implement the hw_constraint
for coupling those numbers, too.  Then application may choose the
init_chunk or step_chunk, which restricts the period size
automatically.  If application doesn't choose those, the hw_params
engine will choose depending on the period size, and application can
see the values after hw_params call.


thanks,

Takashi