[LAD] ALSA POLLIN event problems

[fons at kokkinizita.net]

On Tue, Jan 25, 2011 at 10:30:16AM -0500, Paul Davis wrote:

> On Thu, Jan 20, 2011 at 7:40 PM, Louis Gorenfeld
> <louis.gorenfeld at gmail.com> wrote:
> > Hey, I've been having a lot of trouble with ALSA and processing input
> > in a full duplex loop, and I was wondering if anyone here had any
> > insight.  I'm using the ALSA poll file descriptor method with the mmap
> > routines.  Typically, my processing loop is blowing past the poll
> > statement with input requests (POLLIN), causing the CPU usage to go
> > off the charts as it's basically looping as fast as it can go.
> >
> > Now, I'm handling the inputs in a way that might not be correct.
> > Often, ALSA is saying that the available frames is 1.5 times my buffer
> > size (e.g., I set a 64 sample buffer and ALSA offers me 96 samples).
> > I only get (begin/commit) input when the buffer size matches or
> > exceeds the buffer length I send out to the card (the set buffer
> > size), and if it exceeds that, I only pick up (commit) one buffer's
> > length of frames.  Is this wrong?  If there is more input waiting,
> > does ALSA immediately go and POLLIN again, or should I expect it to
> > not bug me again until I've processed a POLLOUT event (the in and out
> > are linked)?  I'm not really sure how to handle this..
> 
> the in & out are not linked in any way as far as ALSA is concerned
> (even though they may be at the h/w level).
> 
> a 64 sample buffer (not period) is very, very small. you need very
> tight code and a well configured machine to operate like this. what
> period size and/or number of periods are you attempting to use?

You (Louis) could have a look at how libclalsadrv handles this
(or just use it :-). It's very similar to Jack's ALSA backend,
early versions were actually based on it.

Ciao,

-- 
FA

There are three of them, and Alleline.