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>
