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

[Jaroslav Kysela <perex@perex.cz>]

On 3/31/26 08:36, Takashi Iwai wrote:

>>> 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.

I was more thinking about this problem and it seems that the root of this 
cause is that application (pipewire) is trying to bypass the period based 
mechanism for which we already have the handshake. It's no issue to ask for 
smaller periods from the app side to maintain the expected latency. It is also 
understandable that we need to fill at least two periods at start and keep 
this buffer timing (also with counting the system scheduling latencies).

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.

And saying this, it appears that the kernel drivers (yes SOF) are trying the 
bypass the period constraints make it freely customized [1] instead to apply 
constraints based on the hardware limits including the internal maintenance 
(CPU <-> DSP buffering). So the issue is on both sides and the things are 
failing because the standard period handshake is not honored.

					Jaroslav

[1] 
https://github.com/thesofproject/linux/pull/5673/changes#diff-d8bbc05d879b6eee2041d6fc0ee06f050be097ac05b12cfec9b35d89f66d3a84R79-R89

/*
  * When the host DMA buffer size is larger than 8ms, the firmware switches from		
  * a constant fill mode to burst mode, keeping a 4ms threshold to trigger 		
  * transfer of approximately host DMA buffer size - 4ms after the initial burst		
  * to fill the entire buffer.		
  * To simplify the logic, above 20ms ALSA period size use the same size for 
host		
  * DMA buffer, while if the ALSA period size is smaller than 20ms, then use a		
  * headroom between host DMA buffer and ALSA period size.		
  */

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