[pulseaudio-discuss] Google ChromeOS reinventing the wheel, ignoring PulseAudio

[Arun Raghavan]

On Thu, 2011-10-06 at 21:14 -0700, Dylan Reid wrote:
>         > Obviously we're somewhat biased here, but I think it would
>         be prudent of
>         > you to revisit some of the previous results. Pierre has done
>         a lot of
>         > work on the Intel side and numerous other companies are
>         using PA in an
>         > embedded space without any of the CPU problems you mention.
>         There was
>         > indeed a "period of pain" where such issue were caused, most
>         typically
>         > from the timer based scheduling mechanism that PA implements
>         which many
>         > underlying ALSA drivers did not play nicely with. Since then
>         lots of the
>         > driver issues were fixed.
>         
>         
>         Yes, the general experience has been that Pulse does well in
>         embedded
>         environments - power problems with it are pretty much always
>         down to
>         issues in the drivers propagating up the stack rather than
>         Pulse itself.
>         There's production hardware out there using Pulse which would
>         really
>         notice.
>  
> I took some quick measurements of alsa and pulseaudio playback on an
> Acer Chromebook.  I tested with a latency of 200ms and 10ms.  I used a
> pulse audio at commit b0d9c78 plus a patch I got from Pierre-Louis to
> avoid SRC if possible(attached).  These are the results I got.  Two
> problems, it's using a ton a CPU in the low latency case, and it when
> asked for 10ms latency it was giving me around 50ms.
> 
> 
> This table shows the cpu usage measured with 'top -d10 -n2 -b'.  I
> attached the python script I used to run the test in case anyone wants
> to reproduce.

Just as a sanity check, I hope you're running these tests with the CPU
frequency pegged at a single value. top numbers are a percentage of the
current CPU frequency.

>  I've attached the PA config files I am using, along with the log
> output(pulselog).  The most suspicious thing in there is the failure
> to get RT scheduling.  Is there something obviously wrong with the
> configs that would cause these numbers to be so high, or to prevent
> 10ms latency working?

At some point, you might want to build PulseAudio with Orc[1] support
enabled for performance gains[2] when software volumes are applied.

Cheers,
Arun

[1]: http://code.entropywave.com/projects/orc/
[2]:
http://lists.freedesktop.org/archives/pulseaudio-discuss/2010-October/007952.html