Question

I’ve got an audio application which uses ALSA drivers on linux, and the code works quite well on an intel linux desktop machine. However, I would also like to support the Raspberry Pi, and I am getting periodic audio dropouts and buffer underruns on that platform. To be fair, the underruns also occur on intel linux, but they are not accompanied by the nasty static bursts, which probably has to do with the ALSA driver on that platform.

Anyways, I am getting two types of errors. First, my call to snd_pcm_wait() sometimes returns the -EPIPE code. I catch this code and then try to call snd_pcm_recover() and then snd_pcm_prepare(), but a bit of static distortion still occurs in the subsequent call to snd_pcm_writei(). Is this the correct way to recover from such errors? Is there a way to recover from this without the static?

When snd_pcm_wait() returns successfully, I call snd_pcm_avail_update()… should I also do this after a successful return from snd_pcm_recover()?

The second problem I have is that sometimes snd_pcm_writei() also returns the -EPIPE return code. Again, I try calling snd_pcm_recover() in this case, but still get audible clicks or other nastiness. Is there a way to recover from this error more gracefully?

Answer 1

Underruns can happen at any time, so any function can return -EPIPE.

snd_pcm_recover() already has called snd_pcm_prepare() if it succeeds; you do not need to call it again.

When a device is prepared, its buffer is reset. In other words, it is known to be completely empty, so you don’t need to check how many frames are available.

Due to the reset, you should hear only the data that you’ve written to the buffer afterwards.
Any static would be some leftover garbage from the underrun and indicates a bug in the driver.
There’s nothing that your application can do about that.