25 Jan
2011
25 Jan
'11
4:30 p.m.
On Thu, Jan 20, 2011 at 7:40 PM, Louis Gorenfeld
<louis.gorenfeld(a)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?