[pulseaudio-discuss] CPU usage when resampling

[Lennart Poettering]

On Tue, 11.12.07 11:43, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> Hi,
> 
> I'm trying to help a user who seems to be having a bad experience with
> Pulse on a pretty powerful machine.
> 
> If people have experience with pulse and resampling, especially with the
> 'speex-float-3' resampler, please let me know.
> 
> I could quote the full information here but it's probably better to just
> link to the Mandriva discussion:
> http://archives.mandrivalinux.com/cooker/2007-12/msg00352.php
> 
> Short synopsis (all info from above link):
> 
> - Pulseaudio needs a terrible amount of CPU time: on my Athlon 64 3500,
> playing sound through Rhythmbox - Gstreamer (with the Gstreamer
> properties now set to output to PUlseaudio), Pulseaudio uses between 6 -
> 10 % of CPU time.

6% is not that bad. Also note that Gst defaults to comparatively small
fragment sizes, which causes a higher CPU load than playing back the
same file on other players would cause.

If the HW can only do 48k and the stream to play is 44.1k then
resampling needs to take place. This is done in PA now, while
previously it was done inside of the playback application, inside of
libasound. I.e. while you previously couldn't "see" the CPU load of
the resampling because it didn't show up seperately in "top", it does
now. So please don't be confused: resampling requires a non-trivial
amount of CPU. I did so before PA came into play and it still does
now.

Yes, the PA resampler (which is the speex resampler) takes up more CPU
then the ALSA one. That's simply because the ALSA resampler was
unbearibly bad in quality. 

The Speex resampler is the fastest fully free resampler we have
now. If you still think it eats to much CPU then you're welcome to add
native SSE/vectorization support. I am sure Jean-Marc would be happy
about that too. 

Please make sure to compile PA with -O3 and -ffast-math. Otherwise the
CPU load taken up by resampling is 3x slower (or more).

> - When I started restoring some minimized applications, sound began to
> stutter, and finally Rhythmbox stopped playing and hung using 100% of
> CPU time. I've never seen a similar problem before with Rhythmbox,

It is rhythmbox which is eating all CPU? Not PA?

> although I use it daily. (This was with GStreamer set again to use Alsa,
> but I guess that means Alsa output was being intercepted by Pulseaudio,
> as it was using CPU time again). Anyway, the sound stuttering also
> happened to me yesterday when I was piping output directly to
> Pulseaudio.

Stuttering? Souns like you get buffer underruns. What kind of kernel
is this? Please make sure to run a kernel with HZ=1000 and
CONFIG_PREEMPT. If your kernel doesn't have that, then I kindly ask to
change distribution to something that is more useful for desktop
use. (i.e. install Fedora!)

> alsa_output.pci_10de_59_alsa_playback_0 with sample spec s16le 2ch
> 44100Hz and channel map front-left,front-right
> D: memblockq.c: memblockq requested: maxlength=70560, tlength=35280,
> base=4, prebuf=33516, minreq=1764
> D: memblockq.c: memblockq sanitized: maxlength=70560, tlength=35280,
> base=4, prebuf=33516, minreq=1764
> 
> 
> Anyone have similar experience?

No!

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4