On Tue, Jan 25, 2011 at 10:30:16AM -0500, Paul Davis wrote: > On Thu, Jan 20, 2011 at 7:40 PM, Louis Gorenfeld > <[email protected]> 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. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
