[pulseaudio-discuss] Google ChromeOS reinventing the wheel, ignoring PulseAudio
dgreid at google.com
Sun Oct 9 23:59:40 PDT 2011
On Sun, Oct 9, 2011 at 7:36 PM, Arun Raghavan <arun.raghavan at collabora.co.uk
> 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
> > 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 support
> enabled for performance gains when software volumes are applied.
Thanks for the pointer. I hadn't heard of Orc before, I'll take a look.
> : http://code.entropywave.com/projects/orc/
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the pulseaudio-discuss