21 Jan
2011
21 Jan
'11
1:40 a.m.
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..
Cheers,
Louis
25 Jan
25 Jan
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?
5:11 p.m.
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(a)gmail.com> wrote:
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.
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?
4848
days inactive
4852
days old
linux-audio-dev@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
fons＠kokkinizita.net -
Louis Gorenfeld -
Paul Davis