Reviewing and deciding upon a default buffer size strategy for ALSA

[mitchmindtree]

#401 finally allows users to specify a fixed buffer size, allowing some control over the trade-off between energy efficiency and low latency.

The BufferSize::Default value allows the user to fallback to whatever the default buffer is provided by the host. However, ALSA is a bit of a special case in that the default size can be extreme, sometimes implying a delay from multiple seconds up to a minute - an impractical delay for the majority of applications. As a temporary workaround, #401 has opted to leave the BufferSize::Default branch to select a ~100ms delay to match what was previously hard-coded. I've opened this issue so that we can discuss a more suitable default strategy for ALSA.

See here and here for prior discussion on potential strategies. Of note, @sniperrifle2004 made the following suggestion:

As an alternative suggestion to the lowish 100ms aplay does this by default: Get the maximum buffer time. Cap it at half a second. Then restrict the period time to near a quarter of this buffer time (It's where I got that metric from. aplay has been immensely useful as both a reference implementation and a tool) and then restrict the buffer time to near the chosen value.

[diwic]

What latency would BufferSize::Default typically result in on other platforms? That could be what we would typically cap the max buffer time on ALSA, ensuring somewhat consistent behavior between platforms.

Then restrict the period time to near a quarter of this buffer time

Two periods are usually sufficient, especially on high latencies (hundreds of ms), and means less wakeups.

[sniperrifle2004]

Two periods are usually sufficient, especially on high latencies (hundreds of ms), and means less wakeups.

That is true. aplay takes a conservative approach here. However, since the user is unable to affect the number of periods in the buffer directly, I think some "just in case" fallout protection is appropriate.

[kawogi]

What about enforcing a limit for the acceptable range à la: BufferSize::Default(min, max)
That would still allow to select a value the system feels comfortable with but without accidentally ruining the experience. Using the max range would still allow to disable this limitation.

[dani-corie]

I'm not sure I'd still call that Default though... How about BufferSize::Range(min, max), while keeping BufferSize::Default for the real 'don't care, whatever the backend gives me' scenario?

And at that point, when specifying a range, it would be really welcome to have a hard guarantee for the maximum number of samples the callback will be called for, in case we're using some kind of internal work buffer with a fixed size.

[roderickvd]

In latest master quite some work went in to make cpal follow the device defaults (yes, assuming the system is properly set up) instead of cpal default (for ALSA: the 100 / 25 ms taken from aplay). As one advantage, people have started to notice that their PipeWire quantum configurations are now properly followed.

On the way forward:

1. There's frequent requests to somehow clamp buffer sizes through some variant of Near(min, max) or Range(min, max) as coined above. I like Range more because ALSA already does set_buffer_size_near to byte-align with whatever the driver needs.

2. A proposed StreamConfigBuilder would allow for ergonomic fallbacks like:

let config = device
    .default_output_config()?
    .build_config()
    .with_buffer_size(512)
    .or_else(|_| {
        // Fallback to smaller buffer if 512 not supported
        device
            .default_output_config()?
            .build_config()
            .with_buffer_size(256)
    })?
    .build();

3. Definitely we should honor various requests to query a stream's actual buffer size so that users can take whatever action they want.

[yara-blue]

A proposed #956 (comment) would allow for ergonomic fallbacks like:

How about passing in a range and where cpal tries to pick either the larges or smallest in that range and increases up to the supported value?

[roderickvd]

As in, taking Range<Idx> as an argument?

[yara-blue]

Something like this:

    let builder = MicrophoneBuilder::new()
        .default_device()?
        .default_config()?
        // We want the lowest buffer size possible that's
        // higher then this minimum
        .prefer_buffer_sizes(4096..);

This API takes IntoIterator:

    pub fn prefer_buffer_sizes(
        &self,
        buffer_sizes: impl IntoIterator<Item = u32>,
    ) -> MicrophoneBuilder<DeviceIsSet, ConfigIsSet, E> {

So arrays work as well

     let builder = MicrophoneBuilder::new()
         .default_device()?
         .default_config()?
         // Multiples of two work well for us
         .prefer_buffer_sizes([
             2048.try_into().expect("not zero"),
             4096.try_into().expect("not_zero"),
         ]);