Zeno Sebastian Endemann

Yes, I understood so far. But the default setting is `snd_pcm_hw_params_set_drain_silence(1)` - does that mean the alsa lib will internally do basically these manual workaround steps you mentioned for you?...

> > 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...

> When 0 < silence_threshold < buffer_size, then the driver ensures that there is always a number of silence samples _ahead of_ the appl_ptr in the buffer, so that if...

> No. It is the appl_ptr which is rewound, so the xrun point is made earlier (subject to the stop_threshold setting of course). The next write from the application will...

I kind of question the usefulness of the drain state/operation in general, as one seemingly could always just as well simply intentionally wait for the underrun when one is done...

> The internal implementation details should not be in documentation IMHO. The overriding is hidden (silence sw_params from the caller are returned back when drain is finished). The documentation should...

> On the other side, the current silencing is not a perfect solution without a smooth sample value change to zero implementation. So it does not omit pops completely, if...

With my patch about the silence param interaction merged now, I am wondering if it is worth it to amend the `snd_pcm_hw_params_set_drain_silence` documentation to recommend just leaving this option enabled...

What do you mean by "it cannot be precise by design"? As far as I can see, a simple addition to the plugin api (for compatibility of course an opt-in)...

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 API...