<br><br><div class="gmail_quote">On Sun, Oct 9, 2011 at 7:36 PM, Arun Raghavan <span dir="ltr"><<a href="mailto:arun.raghavan@collabora.co.uk">arun.raghavan@collabora.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="HOEnZb"><div class="h5">On Thu, 2011-10-06 at 21:14 -0700, Dylan Reid wrote:<br>
> > Obviously we're somewhat biased here, but I think it would<br>
> be prudent of<br>
> > you to revisit some of the previous results. Pierre has done<br>
> a lot of<br>
> > work on the Intel side and numerous other companies are<br>
> using PA in an<br>
> > embedded space without any of the CPU problems you mention.<br>
> There was<br>
> > indeed a "period of pain" where such issue were caused, most<br>
> typically<br>
> > from the timer based scheduling mechanism that PA implements<br>
> which many<br>
> > underlying ALSA drivers did not play nicely with. Since then<br>
> lots of the<br>
> > driver issues were fixed.<br>
><br>
><br>
> Yes, the general experience has been that Pulse does well in<br>
> embedded<br>
> environments - power problems with it are pretty much always<br>
> down to<br>
> issues in the drivers propagating up the stack rather than<br>
> Pulse itself.<br>
> There's production hardware out there using Pulse which would<br>
> really<br>
> notice.<br>
><br>
> I took some quick measurements of alsa and pulseaudio playback on an<br>
> Acer Chromebook. I tested with a latency of 200ms and 10ms. I used a<br>
> pulse audio at commit b0d9c78 plus a patch I got from Pierre-Louis to<br>
> avoid SRC if possible(attached). These are the results I got. Two<br>
> problems, it's using a ton a CPU in the low latency case, and it when<br>
> asked for 10ms latency it was giving me around 50ms.<br>
><br>
><br>
> This table shows the cpu usage measured with 'top -d10 -n2 -b'. I<br>
> attached the python script I used to run the test in case anyone wants<br>
> to reproduce.<br>
<br>
</div></div>Just as a sanity check, I hope you're running these tests with the CPU<br>
frequency pegged at a single value. top numbers are a percentage of the<br>
current CPU frequency.<br></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> I've attached the PA config files I am using, along with the log<br>
> output(pulselog). The most suspicious thing in there is the failure<br>
> to get RT scheduling. Is there something obviously wrong with the<br>
> configs that would cause these numbers to be so high, or to prevent<br>
> 10ms latency working?<br>
<br>
</div>At some point, you might want to build PulseAudio with Orc[1] support<br>
enabled for performance gains[2] when software volumes are applied.<br></blockquote><div>Thanks for the pointer. I hadn't heard of Orc before, I'll take a look. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br>
Arun<br>
<br>
[1]: <a href="http://code.entropywave.com/projects/orc/" target="_blank">http://code.entropywave.com/projects/orc/</a><br>
[2]:<br>
<a href="http://lists.freedesktop.org/archives/pulseaudio-discuss/2010-October/007952.html" target="_blank">http://lists.freedesktop.org/archives/pulseaudio-discuss/2010-October/007952.html</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
pulseaudio-discuss mailing list<br>
<a href="mailto:pulseaudio-discuss@lists.freedesktop.org">pulseaudio-discuss@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss" target="_blank">http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss</a><br>
</div></div></blockquote></div><br>