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.
