[pulseaudio-discuss] PulseAudio Painfully Slow

Alexander E. Patrakov patrakov at gmail.com
Mon Jul 14 08:50:01 PDT 2014

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

More information about the pulseaudio-discuss mailing list