[BUG?] Setting (start_threshold > stop_threshold) makes snd_pcm_writei(a_small_buffer) XRUN immediately

[Geraldo Nascimento]

On Sat, Oct 02, 2021 at 01:31:12AM +0800, Zhang Boyang wrote:
> Hello,

Hello, Zhang!

> 
>    I'm using ALSA to develop an audio-streaming application. I try to 
> use start_threshold and stop_threshold in combination with small 
> buffers. However, I think I probably found a bug about this.
>    I'm setting start_threshold=100 and stop_threshold=50. I'm also using 
> a buffer of 44 frames. When I call 
> snd_pcm_writei(the_small_44_frames_buffer), pcm state came to XRUN from 
> PREPARED directly. I think this is a bug because the stream hasn't 
> started. It's hard to say a xrun occurred while stream not started.
>    I'm wondering if this is a ALSA-bug or a misuse of ALSA. A simple bug 
> test program is attached.

No, I don't think it's a bug. You're bound to run into problems with a
period size of only 44 frames.

Moreover, working with the code you provided, I was able to get a RUNNING
state without XRUNs with a period size of 4410 frames (100 milliseconds of
audio) but I had to comment out snd_pcm_sw_params_set_stop_threshold() for
it to work or I'd have those instant XRUNs.

That's how snd_pcm_sw_params_set_stop_threshold() is supposed to work by
the way. It creates a XRUN once the threshold is hit.

Thanks!
Geraldo Nascimento

>    Thank you very much!
> 
> Zhang Boyang
> 
> p.s.
>    I dug into kernel code. After writting hardware buffer, 
> __snd_pcm_lib_xfer() called snd_pcm_update_state(), which set the XRUN 
> state.