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

[Dylan Reid]

On Sun, Oct 9, 2011 at 7:36 PM, Arun Raghavan <arun.raghavan at collabora.co.uk
> wrote:

> 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 believe they were sane at least in this respect.  I turned off our power
daemon and put all the CPUs to the performance governor before running the
tests.

>
> >  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.
>
Thanks for the pointer. I hadn't heard of Orc before, I'll take a look.

>
> Cheers,
> Arun
>
> [1]: http://code.entropywave.com/projects/orc/
> [2]:
>
> http://lists.freedesktop.org/archives/pulseaudio-discuss/2010-October/007952.html
>
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20111009/414dbdf6/attachment.htm>