[alsa-devel] ALSA processor usage is too high

Adam Rosenberg 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
same application?

> 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 mailing list