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

[Jaroslav Kysela <perex@perex.cz>]

On 4/23/26 07:05, Péter Ujfalusi wrote:
> 
> 
> On 22/04/2026 17:19, Péter Ujfalusi wrote:
> 
>> Hrm, so this is a driver scoped refine, right? Based on the requested
>> period size and a flag (SNDRV_PCM_HW_PARAMS_LATENCY_AWARE?) the driver
>> refines the period size based on it's jumpyDMA capabilities?
>>
>> But in this example the application will have no knowledge still how the
>> DMA will move, the DMA will initially move 30ms and after that, every
>> 5ms it moves 5ms, so the driver should be refining to 5ms period size, 6
>> initial periods and 1 period step, no.
>>
>> Or with my favorite examples:
>> 4ms initial burst w/ 1ms steps will refine to 1ms periods, 4 init and 1
>> step.
>> 100ms initial burst w/ 96ms steps will refine to... I'm not sure
> 
> 4ms period size, 25 init periods, 24 step periods?
> 
> and same for
>> 40ms initial burst w/ 36ms steps.
> 
> 4ms period size, 10 init periods, 9 step periods?

Yes, the settled period size will be like the basic transfer block.

I am trying to put things together and create a proposal. Very preliminary 
version is available here [1]. We can discuss this more. It should cover all 
missing pieces in the current PCM API buffering setup (realtime double 
buffering, deep buffer, power consumption optimizations).

I just need to verify, if we can create a constraint for this mechanism. The 
maximal period size from app should define the requested latency (half).

					Jaroslav

[1] https://gist.github.com/perexg/c552e92c38be47c8c4d6768a9c8d40ce

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