[Alsa Host] Start threshold of 0

[sniperrifle2004]

I noticed that currently the start threshold is set to 0 frames:

cpal/src/host/alsa/mod.rs

Line 910 in b177bcd

sw_params.set_start_threshold(0)?;

Now this doesn't seem like a good idea to me. I don't think this has well defined behaviour across devices and it also seems counter intuitive, to start recording/playing before there are any frames. For playback that threshold should probably be the buffer size, while for recording a single frame would work and the resulting semantics would be the same.

Using significantly less than the buffer size for playback could result in underruns (Which lead to all kinds of fun), though with the alsa host's current approach to buffering - "Just use whatever the device uses or well 100ms is okay I guess" - that can still happen for certain applications. Luckily #401 will change that). Now a period size (Or even a single frame) would also work, but it's risky. If an application relies on the buffer, because the source is bursting or can just about make the period time, not filling up the buffer before starting will result in underruns and no amount of changing the buffer size will fix that if the start_threshold is not appropriately set.

EDIT: The alsa pcm example uses a period less then a full buffer. I guess that would work as well.

[sniperrifle2004]

If the intention was to not start the stream until pcm.start(), then setting the start threshold to a high value would be the better approach (That is what latency.c does) since that is well defined. However I believe setting a proper start_threshold would be better forgoing pcm.start(). Otherwise you will still have to ensure data is available deferring the call to pcm.start().

EDIT: That is also what https://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html advices: ie. set a start_threshold of more than the buffer size.

[diwic]

Now this doesn't seem like a good idea to me.

It really is not. However, the exact behaviour should not vary between backends, so I haven't tried changing it, because I don't know how the other backends work.

The alsa pcm example uses a period less then a full buffer.

Not an example from alsa-rs, I hope? The buffer should be completely full before starting, not one period less than a full buffer.

[sniperrifle2004]

Not an example from alsa-rs, I hope? The buffer should be completely full before starting, not one period less than a full buffer.

Actually yes. I'd say it's the example: https://docs.rs/alsa/0.4.2/alsa/pcm/index.html

I agree that a full buffer would be the only right choice in theory, but I wasn't able to trigger a problem with the nearly full buffer. As part of #433 I initially had trouble getting it to fail at all. It turns out that the alsa plugins are very effective at masking underruns.

[diwic]

Actually yes. I'd say it's the example: https://docs.rs/alsa/0.4.2/alsa/pcm/index.html

Ehm, must have been a mind glitch on my part. But as you say, it does not matter much in practice.

[est31]

9503ab7