<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> Obviously we're somewhat biased here, but I think it would be prudent of</div>
<div class="im">
> you to revisit some of the previous results. Pierre has done a lot of<br>
> work on the Intel side and numerous other companies are using PA in an<br>
> embedded space without any of the CPU problems you mention. There was<br>
> indeed a "period of pain" where such issue were caused, most typically<br>
> from the timer based scheduling mechanism that PA implements which many<br>
> underlying ALSA drivers did not play nicely with. Since then lots of the<br>
> driver issues were fixed.<br>
<br>
</div>Yes, the general experience has been that Pulse does well in embedded<br>
environments - power problems with it are pretty much always down to<br>
issues in the drivers propagating up the stack rather than Pulse itself.<br>
There's production hardware out there using Pulse which would really<br>
notice.</blockquote><div> </div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div><div><font class="Apple-style-span" face="'courier new', monospace">| device / test | 44.1 | 48k | 44.1 and 48k mixed | two 44.1 streams | two 48k streams |</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">| aplay -Dplughw:0 -B10000 | 2% | 1% | -- | -- | -- |</font></div><div><font class="Apple-style-span" face="'courier new', monospace">| aplay -Dplughw:0 -B 200000 | 0% | 0% | -- | -- | -- |</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">| aplay -Dplug:dmix -B 10000 | 1% | 1% | 2% | 2% | 2% |</font></div><div><font class="Apple-style-span" face="'courier new', monospace">| aplay -Dplug:dmix -B 200000 | 1% | 1% | 2% | 2% | 3% |</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">| pacat --latency-mesc=10 | 18% | 15% | 30% | 22% | 23% |</font></div><div><font class="Apple-style-span" face="'courier new', monospace">| pacat --latency-msec=200 (pulseaudio + pacat) | 2% | 1% | 2% | 5% | 5% |</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">| aplay -Dpulse -B 200000 (pulseaudio + aplay) | 8% | 2% | 5% | 4% | 7% |</font></div><div><font class="Apple-style-span" face="'courier new', monospace"><br>
</font></div><div><font class="Apple-style-span" face="'courier new', monospace">aplay -Ddefault -B 10000 44.1.wav and aplay -Ddefault -B200000 48k.wav: 2%</font></div><div><font class="Apple-style-span" face="'courier new', monospace">pacat --latency-msec=10 --rate=44100 44.1.wav and 2</font><span class="Apple-style-span" style="font-family: 'courier new', monospace; ">pacat --latency-msec=200 --rate=48000 48k.wav</span><font class="Apple-style-span" face="'courier new', monospace">: 24%</font></div>
<div><br></div></div><div> 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?</div>
<div><br></div><div>Thank you for your interest and advice,</div><div><br></div><div>Dylan</div></div>