[alsa-devel] Handling non-buffer-sized MMAP requests

[Raymond Yau]

2010/12/13 Clemens Ladisch <clemens at ladisch.de>

> louis at museresearch.com wrote:
> > Hi everyone, I'm having some difficulty improving a full-duplex MMAP ALSA
> > 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.  :-)
>
> > 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.
>
> (In the case of capturing, latency does _not_ depend on the buffer size,
> so you should make the buffer as big as possible.)
>
>
Refer to http://thread.gmane.org/gmane.linux.alsa.devel/66826/focus=66954

you mention that snd_pcm_forward can be used to recover from an underrun
condition for playback

In underrun/overrun of playback/capture , the hardware pointer is ahead of
the application pointer

Can snd_pcm_forward be used to recover from overrun in  capture when
automatic stop is disabled ?

Why does  Pulseaudio server request rewind at  the end of underrun ?

D: protocol-native.c: Requesting rewind due to *end of underrun*