Re: [LAD] ALSA POLLIN event problems

From: Paul Davis <paul@email-addr-hidden>
Date: Tue Jan 25 2011 - 17:30:16 EET

On Thu, Jan 20, 2011 at 7:40 PM, Louis Gorenfeld
<louis.gorenfeld@email-addr-hidden> 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?
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Jan 25 20:15:02 2011

This archive was generated by hypermail 2.1.8 : Tue Jan 25 2011 - 20:15:02 EET