Jaroslav Kysela

> can I assume draining will work without any glitches at the end for all hardware, independently of the sw_params silence params? I think the documentation should be a bit...

> Anyway, just to re-confirm, do I understand correctly that when `snd_pcm_hw_params_set_drain_silence` is active, the silence_threshold/size parameters only potentially influence the underrun situation, as for when draining the alsa-lib will...

> The documentation should be clear about what alsa will take care for you and what the app developer needs to do themselves, right? I meant that we should describe...

I miss what you suggest. The ioplug interface cannot be precise by design.

I mean atomicity for hw_ptr (avail) + timestamp updates. Unless we have a real use (external plugin) providing timestamps, this extension in alsa-lib is not necessary. The note about `snd_pcm_status_get_avail()`...

> I'm not quite sure I understand your arguments. Here is my motivation for this; as an application developer it would be nice if I could just use the alsa...

PA have different timestamps: "The returned time is in the sound card clock domain, which usually runs at a slightly different rate than the system clock.". So PA is ruled...

I don't see the time domain there.

Not all hardware support 8 channels, so it would require to add a fallback code to the dmix code.

Follow INSTALL (https://github.com/alsa-project/alsa-lib/blob/master/INSTALL): ``` Compilation of static library ----------------------------- If you would like to use the static ALSA library, you need to use these options for the configure script: ./configure...