[Alsa Host] Set appropriate start threshold depending on the direction

[sniperrifle2004]

I have taken the alsa pcm's approach of a period of the buffer size for playback. Hopefully that fills up the buffer since the next period is coming shortly and can probably be written well within the time it takes to play the first period in the buffer. I don't know if this assumption holds in extremely low latency situations, but if it doesn't I suspect underruns would start happening anyway.

Fixes #432

[mitchmindtree]

Thanks for diving into this! And thanks for taking a close look into the ALSA backend in general - I've already learned a few new things reading through your recent comments/PRs.

Perhaps we should land #401 first and then base this work on top of that?

[sniperrifle2004]

I'm fine with that. I am still doing some research into this at the moment. It appears that on my machine the fact that poll_descriptors_and_prepare_buffer requests a (nearly) full buffer of frames the first time is sufficient to prevent buffer underruns even with the pcm starting while no data is available in the buffer. However whether this will always be the case is harder to say. It's not something I personally would want to rely on given my current understanding of the semantics, but it might also mean that I have misunderstood something in the semantics and that this is actually perfectly fine (provided the application is able to provide the initial buffer contents fast enough).

[sniperrifle2004]

It appears that on my machine the fact that poll_descriptors_and_prepare_buffer requests a (nearly) full buffer of frames the first time is sufficient to prevent buffer underruns even with the pcm starting while no data is available in the buffer.

That hypothesis can be scrapped. My understanding of the semantics involved was correct. I can now confirm that this will definitely result in under-runs. In fact it happens immediately at the handle.start() if you talk directly to a hardware device. So it's likely that features on the software level have been helpfully hiding this problem to some extend. Plugins like pulse/dmix/plug a lot of cards have for the (sys)default configuration. That might also explain why my less powerful system was stuttering despite not showing under-runs: Under-runs were occurring just not at the cpal level. I have now also reproduced this by talking to the hw:0,0 device on my regular system: Immediate under-run.

[alexmoon]

If you set the start_threshold for capture streams to 1, I think you would not have to call start() here at all.

[mitchmindtree]

@alexmoon any chance you might be interested in getting this work over the line in a new PR? My understanding on this is a bit vague, but it sounds like this might help with some of the initial underruns that can occur when kicking off an ALSA stream?

[alexmoon]

@mitchmindtree yes, I can work on that. I'd probably like to combine this change with #431 since they're related and wait until #506 is merged so we don't have too many outstanding PRs touching the same files.

[sniperrifle2004]

@alexmoon You may be right. I vaguely recall trying 1 and it not working. I then hypothesized that it was due to readi not getting called at all if the pcm is not running and the start_threshold for recording relying on that to switch the pcm to running. But that memory is shaky at best and I am not an expert.

[sniperrifle2004]

@alexmoon Well it seems like I actually have some evidence to back up that memory in commit 3d1ecbe . The log message also goes into the technical details of the hypothesis. Note also that I thought it worked in the earlier commit since I had not actually removed the handle.start()? yet.

[alexmoon]

Yes, that seems to be correct. In my other implementation I was using readi() and a start_threshold of 1 worked correctly.

[sniperrifle2004]

Superseded by #520