On 2021/10/2 12:45, Geraldo Nascimento wrote:
On Fri, Oct 01, 2021 at 10:01:34PM -0300, Geraldo Nascimento wrote:
On Fri, Oct 01, 2021 at 08:33:23PM -0300, Geraldo Nascimento wrote:
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 touse 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.
Oh, and snd_pcm_sw_params_set_stop_threshold() is a little counter-intuitive. The threshold you give the function is compared to the available free space in the ring buffer, not the filled space.
That's why lowering the stop threshold makes XRUNs more likely...
Thanks, Geraldo Nascimento
Zhang,
I was able to make your code work in the end, even with 44 frames writes, which is unadvisable since it eats too much CPU specially if they are low-end like the ARM64 box I'm writing you from.
The trick was to use high values such as 500000. Lower values such as 250000 were enough to trigger XRUNs in my machine. Of course you can set it to -1 and it will ignore XRUNs but that's a bit like setting it to 16777216 or 4096 * 4096 which is a hardcoded limit in alsa-lib, I believe.
And plainly ignoring XRUNs may sound bad under load, believe me.
Thank you, Geraldo Nascimento
Hi,
Thank you for your reply.
I realized my mistake about the meaning of stop_threshold. The stop_threshold should be (bufsz-50), where (bufsz = alsa buffer size). I fixed my code and new code is attached.
However, the problem still exists. I'm trying to minimize audio latency, so I must use a small buffer. In fact, the problem is not related to the absoulte size of buffer, but the relationship between the size of start_threshold, stop_threshold and the buffer. The problem still exists even using manual start mode (i.e. start_threshold>bufsz).
Currently, I'm using a workaround. After PREPARED or XRUN'd, I manually buffer incoming audio frames, and when (n_buffered_frames >= start_threshold && n_buffered_frames >= bufsz-stop_threshold), I write them in a single write() call. Note that the write must in whole, any short write may result in immediate XRUN.
Anyway, Thank you for your advice. Have a nice day. :)
Zhang Boyang