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? > 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..