Handling non-buffer-sized MMAP requests

Handling non-buffer-sized MMAP requests

[louis]

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?  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?  What does it
mean that ALSA is offering me more samples than I have set for the buffer
size?

Cheers,
Louis

Re: Handling non-buffer-sized MMAP requests

[Clemens Ladisch]

louis@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.)


Regards,
Clemens

Re: Handling non-buffer-sized MMAP requests

[louis]

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

Re: Handling non-buffer-sized MMAP requests

[Raymond Yau]

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

> louis@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*