ALSA: Provide info wether HW provides pause/play

[Chief-Detektor]

Hi!
Thanks for this great library! :)
I was a little bit confused that a call to event_loop.pause and event_loop.pause had no effect on my system because I obviously does not have this capability on my HW. This is not a big deal but I thought I would be nice if cpal notifies the users that this feature is not available when calling it in debug mode.
It could prevent others from being confused or even open a bug ticket.

[tomaka]

I agree that there should definitely be a way to report that. Probably one method for the capability, plus make the pause function return a result.

[Chief-Detektor]

Switched my HW and now everything works as expected.
But I recognized that in some situations play and pause (alsa::snd_pcm_pause) might fail returning -77 c_int as error code. It might be desirable to pass the error to the user to indicate if the call failed or succeeded.

[mitchmindtree]

@Chief-Detektor I'm currently thinking a bit about pause behaviour and I'm curious about your case. What device were you using that did not support pause?

I wonder what the effective difference is between creating and destroying the stream vs playing and pausing it. I also can't help but wonder how common it is that devices support "pause" and relative to how often they do not. In downstream projects that require playing/pausing streams frequently (e.g. in a DAW), is it simply up to the user to check for hw pause capabilities, pause if possible, otherwise just destroy their stream and then recreate it when they need to play again? Or perhaps they swap out the callback with one that just writes silence instead?

What got me wondering about this was how to handle streams that are still playing before returning from EventLoop::run #245. It's not super clear to me yet what the expected behaviour across all platforms.

It could be worth checking how JACK, PortAudio and others handle pausing.

The ALSA functions for reference:

• snd_pcm_pause
• snd_pcm_hw_params_can_pause