This not only happens in embedded systems. When I had pulseaudio installed in
my 1.66 GHz dual core notebook, it consumed 8% CPU when playing, as reported by
"top". So let's say pulseaudio was "eating" 133 MHz from my machine, to
DECREASE audio quality, btw. Audio degradation was noticeable, so I dumped it.

Anyway, it's my opinion that I don't own a multi-gigahert computer to hear
shitty audio (or to have an application spending cycles resampling my audio). I
could have bought a cassette player for that.

http://www.amazon.com/b?ie=UTF8&node=172628

(In reply to comment #0)
>   Play a 44100Hz mp3 in n900. It's doing expensive resampling to 48000Hz
> taking around 30% cpu, that drains battery.

I can't quite reproduce that number here.  Using the pre-installed music files
for testing I'm seeing ~10% (pulseaudio) + ~8% (mafw-dbus-wrapper), with the
CPU running @500MHz.

Playing the same files with mplayer confirms they are 44.1KHz but actually uses
more CPU (~16% mplayer + ~6% pulseaudio, same frequency).

Any pointers to a freely-available 48KHz sample?

48khz should show no problem, as no resample would be required.

I have couple of 44k1hz files here, from ages, and most of them cause the
resampling.

Some top output:
  745     1 pulse    S <   4564  1.8 22.8 /usr/bin/pulseaudio --system
--high-pr
  745     1 pulse    S <   4596  1.8 21.3 /usr/bin/pulseaudio --system
--high-pr

so not 30% but around 20-25.

Created an attachment (id=1507) [details]
pactl list result on n900 and 

Find attached result of "pactl list" with information about pulseaudio while
reproducing the audio. You can see "Resample method: speex-fixed-2" in  Sink
Input #2579. Lennart said there is a faster alternative Palm PRE uses.

Found a 48KHz file, but playing it back has very little difference in CPU usage
(still @500MHz):

  PID  PPID USER     STAT   RSS %MEM %CPU COMMAND
  737     1 pulse    S <   4460  1.8 11.6 /usr/bin/pulseaudio --system
--high-pr
 1324   652 user     S <   7236  2.9  9.7 /usr/bin/mafw-dbus-wrapper
mafw-gst-re

I agree it could be better, but it doesn't look like resampling is the problem
to me.

Comment 6 Andre Klapper 2009-10-27 17:55:11 UTC

Please provide *exact* steps how to reproduce.
Also, any test mp3s that you could (legally) provide?

I'd love to see this confirmed by a second person...

(In reply to comment #6)
> Also, any test mp3s that you could (legally) provide?

For 44.1KHz you can use the ones that come pre-installed on the device.  For
48KHz I found some CC ones at <http://www.archive.org/details/STERE02>.  "Seas"
makes pulseaudio use around 12-15% CPU and mafw-gst-renderer 8-10%, tested with
both the VBR and 320kbps (in the large .zip download) versions.

Comment 8 Andre Klapper 2009-11-03 19:13:15 UTC

Hmm. I don't really see a big difference here and this is most likely a WONTFIX
because of that...

Hey all, sorry not replying earlier.

All I can say is that I can reproduce the higher CPU when using 44k1hz files,
but on the other hand it does not drain so much battery as I anticipated. I'm
frequently doing 3h travels listening to music and battery is not that low
after it.

So:
  1. I really confirm that
  2. WONTFIX solution is not that bad
  3. but if there is a way to easily improve it, why not?

For the record, Palm code is in patch
http://palm.cdnetworks.net/opensource/1.2.1/pulseaudio-0.9.14-patch.gz with
main file being src/pulsecore/palm/palm-resampler.c that is NEON optimized.

Fremantle pulseadio uses speex resampler with ARM NEON optimizations:
[sbox-FREMANTLE_ARMEL: ~] > apt-get source libspeex1
[sbox-FREMANTLE_ARMEL: ~] > cat
speex-1.2~rc1/debian/patches/0002-resample-optimization-for-resampler_basic_direct_32.patch

Having to perform 44.1->48KHz conversion should normally cost something like
~1% of extra CPU usage at 500MHz. It would be nice to have some benchmark
numbers verified.

Did some benchmarks, audio samples are available at:
http://siarhei.siamashka.name/files/20091121/

Test with CPU clock frequency set to 600MHz and audio output to headsets (the
most easy case):

echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
top -d 30

44.1 khz: pulseaudio cpu load = ~4.6%
48   khz: pulseaudio cpu load = ~4.0%

Test with CPU clock frequency set to 250MHz and audio output to speakers (the
most heavy case):

echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 250000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
top -d 30

44.1 khz: pulseaudio cpu load = ~21.9%
48   khz: pulseaudio cpu load = ~20.1%

Looking at these results, resampling does not seem to be the biggest pulsaudio
problem to me.

(In reply to comment #9)
> Hey all, sorry not replying earlier.
> 
> All I can say is that I can reproduce the higher CPU when using 44k1hz files,
> but on the other hand it does not drain so much battery as I anticipated. I'm
> frequently doing 3h travels listening to music and battery is not that low
> after it.
> 
> So:
>   1. I really confirm that

How much of the CPU load increase do you actually see? Appears that we have
somewhat contradicting reports now.

Could it be that you had DVFS causing some erratic CPU frequency jumps and
messing up the results in your test environment?

>   2. WONTFIX solution is not that bad

Yes, either this or INVALID.

>   3. but if there is a way to easily improve it, why not?
> 
> For the record, Palm code is in patch
> http://palm.cdnetworks.net/opensource/1.2.1/pulseaudio-0.9.14-patch.gz with
> main file being src/pulsecore/palm/palm-resampler.c that is NEON optimized.

I would definitely love to see some performance patches ported from Palm to
Fremantle pulseaudio if they actually help and if they do not cause any
regressions.

Comment 13 Andre Klapper 2009-11-21 20:05:48 UTC

(In reply to comment #12)
> I would definitely love to see some performance patches ported from Palm to
> Fremantle pulseaudio if they actually help and if they do not cause any
> regressions.

Which ones of them? Lennart has taken a look himself and will include the
useful stuff in upstream Pulseaudio anyway, see
http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg04022.html

(In reply to comment #13)
> (In reply to comment #12)
> > I would definitely love to see some performance patches ported from Palm to
> > Fremantle pulseaudio if they actually help and if they do not cause any
> > regressions.
> 
> Which ones of them? 

I mostly commented the 'way to easily improve it' part of Gustavo's comment.
Realistically, I'm not going to look at this Palm patch myself, but surely
anyone can try it for Fremantle and run some benchmarks. If it proves to be
faster, then why not?

> Lennart has taken a look himself and will include the
> useful stuff in upstream Pulseaudio anyway, see
> http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg04022.html

If Palm resampling optimization gets into upstream pulsaudio, that would be
great too (I quickly looked at pulsaudio git, and it does not seem to be there
yet).

Also apart from performance, another concern is audio quality, that's why right
now NEON optimized version of 'speex-fixed-2' resampler is used, while
'speex-fixed-1' would have been faster (only if it also had NEON
optimizations). Currently only speex-fixed-2 has NEON optimizations because it
is a specifically customized fully unrolled version. Anyway, this particular
part of pulseaudio functionality is fully open source, so I don't see any
problem for anyone to improve it more.

Sorry for joining so late, but I only just noticed some discussions attributing
poor pulseaudio performance to the resampling overhead (and was really
surprised).

Well, while I still notice around 20-30% occasionally, battery is lasting long
enough to just close this bug.

When I reported the bug I was measuring battery during regular device usage and
wondering what was consuming battery, i initially thought it was music, but it
is not, definitely. For example I'm often traveling 2-3 hours with headphones
and battery is not empty... Of course if I turn on horrible Ovi Maps then
battery runs away screaming loud! :-)

*** This bug has been confirmed by popular vote. ***

I can confirm unusual cpu load on mafw-gst-renderer when playing certain media
type. Some files take up to 40% of CPU load (with the associated battery
drain), while others are at 8%. The CPU load also makes animations visibly
jerky, like scrolling; and sometimes even the kernel hangs long enough waiting
for IO to make audio stutter (though that may be unrelated to this).

I'm seeing PA using 29% (sustained) CPU during a google-talk call.

This is enough to push the overall system CPU load above 100%, and it causes
both the video and audio to stutter.

There is a forum posting that says if I use headphones, then this consumption
will drop; it doesn't actually make any noticeable difference.

Is there any way to force pulseaudio into a low-cpu consumption mode? I'd
happily trade hi-fi audio for 8kHz, 8-bit mono, if we can get PA to use only 1%
of CPU. Or can we remove it
entirely, and just use Alsa's dmix?

I'm using the latest release of everything on the N900, and measuring CPU
consumption via top (over ssh.)

(In reply to comment #17)
> I can confirm unusual cpu load on mafw-gst-renderer when playing certain media
> type. Some files take up to 40% of CPU load (with the associated battery
> drain), while others are at 8%. The CPU load also makes animations visibly
> jerky, like scrolling; and sometimes even the kernel hangs long enough waiting
> for IO to make audio stutter (though that may be unrelated to this).

mafw-gst-renderer performs audio decoding and CPU usage depends on the codec
used. This CPU usage is unrelated to pulseaudio.

(In reply to comment #18)
> I'm seeing PA using 29% (sustained) CPU during a google-talk call.

The PA CPU usage you see is high (due to both audio playback and recording
happening at the same time, which is more CPU demanding than playback alone).
But it has nothing to do with the samplerate conversion and the original
report.

So if anyone finds a case where samplerate conversion causes performance
problems, this bug should be reopened. For anything else, the best thing to do
is to just submit a new bug (doing a search first to be sure that there are no
duplicates).

Thanks. I see what you mean about being hit double; once for recording and once
for playback.

But why is the sound server using *any* CPU at all? That 29% isn't spare: the
telephony app can't run with merely 70%. 

We're using about 1000 CPU cycles per sound-sample. 

Is it possible to reconfigure pulseaudio to be CPU efficient (even if it hurts
sound quality a bit)? Can we set the hardware to natively run at the software's
sample rate? (OR vice-versa). Or can we bypass it (Linux sound worked fine 2
years ago using either OSS or ALSA directly, and never had any userspace
programs wasting so much CPU)

Here's a definitive measurement of just how bad pulseaudio is.

1. With the defaults (and having apt-get installed sox), and with the
headphones unplugged I run:

play /usr/share/sounds/ui-wake_up_tune.wav
/usr/share/sounds/ui-wake_up_tune.wav /usr/share/sounds/ui-wake_up_tune.wav

then in another terminal, run top. 

The file is 11 kHz stereo 16-bit (use "file" to show this). I play it 3 times
consecutively because top takes a few seconds to update the display.

I observe that play is using 6.5% CPU and that PulseAudio uses 24.9%


2. If I apt-get remove pulseaudio and then mv /etc/asound.conf
/etc/asound.conf.orig  and then reboot

I find that play now uses 4.9% CPU, and pulseaudio uses none.


3. In the default configuration, if I plug in the headphones, PA's CPU usage
drops to 8.5%.


Sadly the phone application has a dependency on pulseaudio, but mplayer still
works (and does full-screen video + mp3 decoding at 20% CPU).