* Re: Handling non-buffer-sized MMAP requests
2010-12-13 8:56 ` Clemens Ladisch
@ 2010-12-17 18:56 ` louis
2010-12-18 0:32 ` Raymond Yau
1 sibling, 0 replies; 4+ messages in thread
From: louis @ 2010-12-17 18:56 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel, 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Handling non-buffer-sized MMAP requests
2010-12-13 8:56 ` Clemens Ladisch
2010-12-17 18:56 ` louis
@ 2010-12-18 0:32 ` Raymond Yau
1 sibling, 0 replies; 4+ messages in thread
From: Raymond Yau @ 2010-12-18 0:32 UTC (permalink / raw)
To: ALSA Development Mailing List
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*
^ permalink raw reply [flat|nested] 4+ messages in thread