2 Feb
2011
2 Feb
'11
9:45 p.m.
Am 28.12.2010 00:26, schrieb Nick Copeland:
The CPU load for pulseaudio does not appear to change much with sampling
rate, taking 24kHz, 48kHz gives a very similar profile but you mention a bug
report that notes that fact anyway. Bristol does have a very different footprint
depending on sampling rate and filter selection.
The code will attempt to set the CPU freq to 600MHz when it starts, it does
not necessarily need these cycles but it helps to reduce underruns. Pulse
now rolls along at about 8% to 10% CPU for any rates I have tried and bristol
will take about 8% at 24kHz and double that (17%) for 48kHz.
Sorry for the very late reply. One thing to mention is that the CPU load for
pulse is going wown quite a bit when plugin headphones. Otherwise it runs some
extra processing needed to accomodate the speakers.
Stefan
Now PA does use
quite a lot of CPU on the N900 - the +/-2% it requires on my laptop
translates into about 25% on Maemo, this really is quite an overhead and
as far as I can tell it does not change with sampling rate (I get the
same overhead with 48kHz as with 44.1kHz although I will retest that).
btw, one thing to watch out when doing measurements is the CPU
frequency... N900 uses very aggressive cpufreq and even with heavy audio
processing, the CPU is not necessarily running at full speed (so even if
top shows 25%, that doesn't necessarily mean that only 75% processing
capacity is left for apps). But this is really only a problem when making
measurements (the cpufreq is boosted automatically when needed). There should be no resampling happening (if you
use 48kHz), so it
should not be that. But if src is used in your case, N900 uses speex src
(speex-fixed-2) optimized for arm NEON (see Siarhei's comment in bug for
info and links:
https://test.maemo.org/testzilla/show_bug.cgi?id=5794#c10 ).
This refers to the same data as above, ie, the resampling algorithm is not
where the CPU cycles are being spent. The report discusses the same results
as above but comparing 44.1kHz to 48kHz.
Don't take this too seriously, but I've
personally found it a bit
suprising how much negative feedback there has been about the audio mixer
CPU cycles. In phones (versus desktop/laptops), some processing is needed
as audio quality (especially for voice calls) is a closely followed aspect
(it is benchmarked by various parties and various organizations have
detailed requirements concerning it).
It is sometimes difficult to understand the added value of a given process.
My first reply noted the fact that a complete synth voice with osc/mix/fil/env
and all its internal processing overhead had a lower footprint than the audio
daemon. It is easy to fall into 'Sendmail Syndrome' implying that the process
takes a lot of time, effort (in sendmails case configuration as well) whilst
not evidently bringing much to the table.