linuxaudio.org

For some reason, gmail has stopped delivering my LAD messages, so

apologies if this reply isn't working correctly...
I'm attempting to run, in general, a 128 sample buffer (frames per

fragment).  There is a lower latency mode though which is 64 samples.

I have two fragments.  Maybe if I want to do this I should be using

three at least or make 128 the minimum.
But I'm a little confused at the lack of ins and outs being linked.

For a full duplex loop, I'd have to have the input before I can

process output for example, so I don't see how that works unless I

just ignore input requests from ALSA if I am not yet ready to receive.

 I'm defining "ready to receive input" as the time after I run my

processing loop and then get a POLLOUT request.  However, when I

ignore POLLINs like this, it seems like ALSA immediately POLLINs again

and I wind up with something like 50,000 polling requests handled in a

second, which drives the CPU usage through the roof.
>the in & out are not linked in any way as far as ALSA is concerned

quoted text
>(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..

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev