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

Jaroslav Kysela
2026-03-31T12:00:17Z

On 3/31/26 12:56, Péter Ujfalusi wrote:

> Pipewire uses the minimum period size internally for headroom calculation:
> https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/9c42c06af00818038be494fd41632cb2d50a0df5
>
> This works more or less, but things started to get out of control soon.

It's conditional, so it's not a general rule. Pipewire just tries to push the
drivers to limits with hard-coded assumptions.

> To get the most power saving benefit, you would want quite big
> DeepBuffer, let's say 100ms but for video/voice calls you don't want
> this big buffer, around 40ms should be OK, some other use case might
> need something in between.
> If you run tinyplay on the DeepBuffer PCM w/o specifying period size,
> it will fail to find the minimum and outright fails unless we lower the
> DB to around 20ms.
> With 20ms you don't have much power savings in case of audio playback.
> So, you spam out several PCM devices with different DeepBuffer to
> accommodate use cases, this is really not something that makes sense.
>
> This is the reason why I have reversed the rules and adjusted the
> DeepBuffer size based on the period size.
> In this case we still need to limit how large the DB can be, so it is
> not true that the DeepBuffer equals to the period size, it is caped.

It seems that the discussion somewhere else:

1) applications don't know what they are want, thus driver will enforce a
configuration (e.g. a forced deep buffer)

2) ALSA PCM period mapping to the hardware which allows "deep buffering"

At the moment, nothing prevents ALSA applications to use the bigger period
sizes when there are known beforehand like "play background music". In other
words - power efficiency can be controlled from the app. The applications can
also update PCM buffer at any time, so new data (we are speaking about
playback) can be feed at any time to make the time window for the underrun
occurrence shorter when the driver transfers data to the hardware.

We may have those configurations (* = future when driver tells the initial
count of queued periods):

period | period count | init_periods | minimal data latency |
--------+--------------+---------------+----------------------+---------
4ms | 4 | unsettled (1) | 4ms | realtime
*4ms | 200 | 25 | 100ms | semi-realtime
1000ms | 2 | 1 | 1000ms | pwr efficient

> Strictly locking the DeepBuffer with period size creates another
> obstacle for audio applications, audio servers like PW don't care about
> periods, they work on the buffer with timer based updates and rewriting
> samples in buffer ahead of the hw_ptr.

IMHO, the period size describes the expected minimal latency and applications
can put more samples to the PCM buffer. So the whole question is to give
suggestions which data threshold is safe for the standard operation.

The timer based queuing should just help to feed data more frequently, but it
does not mean that applications should not set the period size based on the
requirements. Ideally, everything should be coordinated - period sizes with
proper sample feed timing from the application side.

Jaroslav

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