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.