Skip to content

Conversation

@roderickvd
Copy link
Member

@roderickvd roderickvd commented Oct 14, 2025

Fixes high latency with BufferSize::Default on PipeWire-ALSA by avoiding period count constraints that cause pathologically large periods.

Fixes

Avoid setting period count when BufferSize::Default is used, allowing
PipeWire-ALSA to select optimal buffer and period sizes. This prevents
excessively large periods and high latency on PipeWire-ALSA devices.
@roderickvd roderickvd changed the title fix: BufferSize::Default behavior on PipeWire-ALSA fix: buffering behavior on PipeWire-ALSA Oct 14, 2025
@roderickvd roderickvd changed the title fix: buffering behavior on PipeWire-ALSA fix(alsa): buffering behavior on PipeWire-ALSA Oct 17, 2025
@roderickvd
Copy link
Member Author

Note to self: drop should wait for two periods worth of time, not the full buffer.

Set buffer_size_near before period_size_near for Fixed buffer sizes to
constrain total latency and avoid extremely large allocations (eg.
PipeWire-ALSA creating ~1M-frame buffers). Then set period_size to keep
double-buffering semantics.

Adjust avail_min by direction: for playback wake when level drops to
one period (buffer - period); for capture wake when one period is
available (period) to prevent excessive capture latency.
Revert to v0.16 behavior: always terminate stream without attempting
state-based drain or wait. Remove buffer-duration calculation and
snd_pcm_wait usage to avoid delays during drop.
Query the device's period size and set buffer_size to 2 * period for
BufferSize::Default. This prevents excessive memory allocation (e.g.
PipeWire-ALSA) while respecting the device's period preference.
This should always align with the two-period double-buffering strategy that we use anyway.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants