[alsa-devel] ALSA processor usage is too high
adam at alcorn.com
Fri Nov 5 20:27:01 CET 2010
On Fri, Nov 5, 2010 at 3:10 PM, Clemens Ladisch <clemens at ladisch.de> wrote:
> When the program is looping and waiting for some free space to become
> available in any of the eight buffers, it doesn't actually process
> audio data. (And you should use poll() with all eight handles so that
> you don't eat CPU while waiting.)
I can't use poll because the application has to perform many other
tasks in a deterministic manner (meaning I can only use threads and
other processes to notify the main loop to perform some task). I
tried using the async callback method so that I could set a flag when
it was time to copy more audio data to the stream but that didn't seem
to work well with multiple streams. I found that polling using
avail_update was the only reliable method. Could you provide an
alternative example that is known to work with multiple streams in the
> The aplay experiment above tells me that your program spent 95% of
> its time calling snd_pcm_avail_update. In that time, you could
> decode instead.
Sorry for the confusion, the main loop of my application basically does this:
so the processNextAlsaStream() function just calls avail_update for
the next stream in my list of 8 streams and then handles the result
before allowing the loop to process the next task.
> Playing silence is not any faster than playing anything else, because
> the sound card _cannot_ run faster than the configured sample rate.
I agree. I only mentioned it was silence so that it was understood I
have a static buffer that I am copying audio frames from so there is
no other processing needed (no reading from a file, etc).
Thank you for your help, I am happy to be discussing this with you all
as it makes me feel as though I am not totally lost. Please let me
know if you have an example of a program that can efficiently handle
multiple PCM streams.
More information about the Alsa-devel