[pulseaudio-discuss] PulseAudio Painfully Slow
lnicola at dend.ro
Mon Jul 14 08:59:47 PDT 2014
While I agree, I think it's only fair to say that both Windows and
PulseAudio avoid the resampling if the source sample rate is the same as
the configured one. In my distribution (Arch), /etc/pulse/daemon.conf
; default-sample-rate = 44100
which means it's the default. Many audio sources are 44.1 kHz, so they
don't need resampling. It might be interesting to see what sample rate
your the slow apps use and whether Pulse isn't configured to use 48000
or something else.
Using pure ALSA I've had some issues with ALSA preferring to open the
device and 48000, but I'm not sure whether this applies to PulseAudio or
On Mon, Jul 14, 2014, at 18:50, Alexander E. Patrakov wrote:
> 14.07.2014 18:32, Clemens Eisserer wrote:
> > Considering the (compared to video) low data rates, I never thought
> > audio can actually be that expensive.
> Well, audio in PulseAudio _is_ more expensive than "video in X server".
> First, the algorithms are more complex. Second, X server doesn't do much.
> In the most common case (OpenGL video output with direct rendering), all
> the heavy processing is done by either the application or by the video
> card. X API simply doesn't have anything more complex than a glorified
> memset or memcpy, and even that was carefully avoided by giving access
> to hardware buffers to the application. In simpler terms, X touches each
> pixel either once or zero times.
> In contrast, most sound-processing algorithms (even resampling) touch
> each sample many times, and all the work has to be done in PulseAudio.
> For concrete numbers, resampling with the quality similar to the default
> quality of Windows XP requires that each output sample is a weighed sum
> of ~28 input samples (easily provable by capturing the output of kvm
> into a wav file). Speex Q1 (default in PulseAudio) needs 16 samples
> (proof: libspeex/resample.c, search for QualityMapping).
> So, it would indeed be quite fair to compare the raw video data rate
> (640x480 pixels * 30 fps * 2 bytes per pixel = 18.4 megabytes per
> second) and audio processing rate (44100 samples per second * 2 channels
> * 2 bytes per channel * 16 accesses = 2.8 megabytes per second). Add the
> fact that X server does just a memcpy in the worst case (and exactly
> nothing in the best case), and PulseAudio does some arithmetics, and
> you'll understand why the CPU usage is of the similar order.
> Alexander E. Patrakov
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
More information about the pulseaudio-discuss