Re: ALSA processor usage is too high

[Clemens Ladisch <clemens@ladisch.de>]

Adam Rosenberg wrote:
> I am not sure how to interpret this, but I told aplay to play for 3
> minutes from /dev/zero and here are the results:
> root:/> time aplay -d 180 -D hw -t raw -f dat /dev/zero
> Playing raw data '/dev/zero' : Signed 16 bit Little Endian, Rate 48000
> Hz, Stereo
> real    3m 0.10s
> user    0m 0.22s
> sys     0m 8.48s

9s / 180s = 5%

> > And what does your program do when avail_update returns 0 frames?
> 
> If it returns 0 then I do not write any frames.  I then check the next
> stream.  This continues in an infinite loop.

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.)

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.

> > You cannot write data faster than it's playing; the audio ring buffer
> > has a finite size.
> >
> > You would have a problem if the processing and/or the driver would
> > make everything so slow that you wouldn't be able to write new data
> > to the device fast enough, which would result in an buffer underrun.
> > Does this actually happen?
> 
> I am currently writing the decoded mp3 data to a buffer in RAM so that
> the program is decoding the mp3 data as fast as it can.  I then run
> the audio process separately and just play silence.  I am doing this
> so that I can tell how much time is being spent decoding mp3 data and
> processing audio data so that I know how much time remains for other
> tasks.

Playing silence is not any faster than playing anything else, because
the sound card _cannot_ run faster than the configured sample rate.


Regards,
Clemens