pulseaudio CPU usage and process name

Lennart Poettering mzerqung at 0pointer.de
Fri Nov 16 23:39:10 UTC 2007


On Fri, 16.11.07 16:58, Callum Lerwick (seg at haxxed.com) wrote:

> On Fri, 2007-11-16 at 22:22 +0100, Lennart Poettering wrote:
> > If you feel that the resampling takes to much CPU, than you're welcome
> > to sit down and add some real MMX/SSE support to the speex resampler,
> > which is the one we're using. ;-)
> 
> Not SRC a.k.a libsamplerate? It would be really nice if everyone could
> just use one resampler, so that resampling could just be done right, and
> done fast, once. Why did speex do their own resampler?

You can change the resampler PA uses by changing the "resample-method"
config option in PA's daemon.conf. We support SRC, the speex
resampler, the ffmpeg resampler and a "trivial" resampler. 

Different resamplers have different properties. The advantage of SRC
is the superb quality, the disadvantages are that it is float-only and
GPL'ed, and thus not really useful on embedded systems and when you
want to load proprietary modules into PA (note that PA is fully
LGPL-licensed, but if you link it against SRC the daemon is
practically "down"graded to GPL).

The good about the Speex resampler is that it can do both float and
integer resampling, that it is BSD-licensed and it is a bit faster
than SRC. 

We chose to make the speex resampler the default. If you prefer the
extra quality of SRC, then you are free to reconfigure
daemon.conf. But trust me, you CPU load is not going to decrease if
you do that ;-).

BTW, if you don't care about the quality of the resampling you can
configure PA to use the "trivial" or "speex-0" resampler. They use
considerably less CPU -- at the cost of quality.

The GPL'dness of SRC is the single reason why SRC never gained that
much of an adoption on systems like gst or alsa.

Lennart

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




More information about the fedora-devel-list mailing list