>
> > 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.
| device / test | 44.1 | 48k | 44.1 and 48k
mixed | two 44.1 streams | two 48k streams |
| aplay -Dplughw:0 -B10000 | 2% | 1% |
-- | -- | -- |
| aplay -Dplughw:0 -B 200000 | 0% | 0% |
-- | -- | -- |
| aplay -Dplug:dmix -B 10000 | 1% | 1% |
2% | 2% | 2% |
| aplay -Dplug:dmix -B 200000 | 1% | 1% |
2% | 2% | 3% |
| pacat --latency-mesc=10 | 18% | 15% |
30% | 22% | 23% |
| pacat --latency-msec=200 (pulseaudio + pacat) | 2% | 1% |
2% | 5% | 5% |
| aplay -Dpulse -B 200000 (pulseaudio + aplay) | 8% | 2% |
5% | 4% | 7% |
aplay -Ddefault -B 10000 44.1.wav and aplay -Ddefault -B200000 48k.wav: 2%
pacat --latency-msec=10 --rate=44100 44.1.wav and 2pacat --latency-msec=200
--rate=48000 48k.wav: 24%
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?
Thank you for your interest and advice,
Dylan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20111006/9d2fda91/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Pierre-s-patch-to-allow-sample-rate-setting.patch
Type: text/x-patch
Size: 38955 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20111006/9d2fda91/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: daemon.conf
Type: application/octet-stream
Size: 2343 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20111006/9d2fda91/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default.pa
Type: application/octet-stream
Size: 2803 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20111006/9d2fda91/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pulselog
Type: application/octet-stream
Size: 18862 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20111006/9d2fda91/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aud_perf.py
Type: text/x-python
Size: 5157 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20111006/9d2fda91/attachment-0001.py>
