Hi Clemens, Thanks for your reply

...

routine. ALSA sometimes reports more samples available for input than my buffer can take, or asks for more samples than I have available. Is this a buffer overrun/underrun?

Yes. (And this should happen only when you've disabled stopping on an xrun, so you've asked for it. :-)

Ok, I found some old code which was enabling this behavior. However, when I took it out, I was still getting more input requests from ALSA than I would expect (e.g. I expect in, out, in out, etc. I get something like in, out, in, in, out sometimes). I am calling snd_pcm_link, which should make the requests go in the correct order, right?

...

If I restart the streams in the case that too much input is available (on the assumption that it's an xrun) it seems to happen at the drop of a hat and makes things worse. If I discard the excess input, that doesn't work well either.

What is the appropriate way to deal with this situation?

The best way would be to prevent this situation from happening, i.e., read the captured data from the buffer before it overflows.

I'm not sure what you mean here. I thought the whole reason it was overflowing was that the CPU was too slow to keep up with the demand. What is the alternative?

(In the case of capturing, latency does _not_ depend on the buffer size, so you should make the buffer as big as possible.)

Could you elaborate on this? How does the input buffer work if the size has no effect on the latency?

Thanks for your time, Louis