ALSA: fix buffer size / period size configuration

[abique]

With ALSA, the buffer size is nperiod * period_size. We want 2 periods ideally.
The default is now set to 1024 samples which is a reasonable default, yet still too large for real-time audio.
Also the default value uses the same code path as custom values.

Fixes #913
Depends on #915 for successful compilation.
Replaces #914

[abique]

It is now a month that this PR is opened.
Can someone review it please?

[SolarLiner]

I have no rights to cpal, so this is symbolic, but having implemented a ALSA backend for my interflow crate, those changes are small enough that there's no worry to merge this.

[abique]

@est31 Hi, any chance this PR gets merged or closed with a comment?
Thanks.

[mbernat]

Hey, I tested this PR and I don't think it works as expected because the PR is not explicitly setting the buffer size at all and I received unexpectedly huge buffers (~1MB) whereas with fixed buffer setting I'm expecting to get a buffer of that exact size.

Full disclosure: we are using alsa's pipewire device and we were struggling with getting buffers of the right size. Because of the former v / 4 period code we were getting buffers quarter the expected size. I have found no combination of settings that would produce correctly sized buffers but it should be possible because we can get those when using PortAudio. But PortAudio has a very complex logic for setting alsa parameters, so I'm not sure how exactly they do it.

[abique]

Buffer size isn't relevant.
What's important is the period size and the number of periods.

[mbernat]

Buffer size isn't relevant.

Can you elaborate? Are you perhaps suggesting that the buffer contains a period size worth of actual samples and the rest is just junk that can be ignored?

We use a webrtc processor for AEC and it seems to require fixed sized buffers. We tried doing buffering ourselves on top of non-fixed buffers given to us by cpal but that introduced timing jitter that prevented AEC to work correctly.

With portaudio we get fixed size buffers and AEC works correctly. To be sure, I'm a beginner when it comes to audio, so it's very much possible I misunderstand some core concepts but it sure does appear that buffer sizes are relevant at least in some cases.

[abique]

An alsa buffer, is a continuous memory used as a circular buffer.
It contains many periods. What alsa calls a period is what asio would call a buffer.

What is important is the period size (in frames) that defines your latency.
You can have a period of 128 samples, work with 2 or 3 periods and have a buffer that could contain a lot more.
The rule is: buffer_size >= perdiod_size * nperiods.

So there's nothing wrong with a bigger buffer, it just takes more memory.
You probably want to shrink your buffer to the minimum required frames.

For alsa, period size and num periods defines your latency and working context.

[mbernat]

Thank you @abique, that makes a lot of sense!

It would be nice to also improve the BufferSize documentation. I'm not sure how much of this behavior is portable between backends but I don't see why there couldn't be an alsa-specific section in the docs. Relatedly, pipewire can also be configured to behave very similarly, from my recent experiments (bigger buffers, fixed periods).