Hi,
On Sun, 19 Dec 2010, Nick Copeland wrote:
> That was a very interesting post, will be keeping it. 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).
You can use standard kernel interfaces to limit the CPU frequencies
(although for sake of your battery, I'd stick to the defaults for all
normal usage).
And another btw, in case someone has missed this, do check Jyri Sarha's
slideset presented at plumber's conf 2009:
http://linuxplumbersconf.org/2009/slides/Jyri-Sarha-audio_miniconf_slides.pdf
E.g. slide 15 has a good diagram of how the pipelines are connected.
Some things to try:
- use an output low overehead output (e.g. headset)
- use srate that matches hw rate (48kHz in this case) ->no SRC is
involved
> I am assuming, possibly incorrectly, that it uses Lennart's correct resampling
> algorithm. Is this the case? If so is there any way an application can request
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 ).
<low-prio>
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). And you can't just solve this by
using a bit better components as the devices are physically so small (and
packed with stuff), are often used in very audio-hostile/noisy
environments, all that makes the acoustics design anything but easy
(and fine-tuning with the help of SW always helps). E.g. the 10" laptop
I'm writing this on has speakers the size of almost half the length of a
phone, and the netbook speakers still sound pretty bad. Maybe the laptop
could use a bit of DSP help as well to get more out of the same hw...
(BruteFIR, anyone..). :P
And OTOH, if the whole thing had been hid on a HW blob (and as is common,
with no possibility to run 3rd party software on it, nor otherwise control
it), roughly same amount of cycles would still be spent, although on
another core (and not showing up in Linux 'top' output). For overall
battery consumption this can (but not of course in all cases) be worse as
the Linux CPU is anyways waking up, so it can be actually more efficient
to do the processing there as well (the caches are hot and CPU already
powered, so doing a bit more work per wakeup is in fact quite efficient).
Now that N900 does this in a more open way, hordes of people are screaming
bloody murder about wasting CPU on processing samples! ;D
Oh well, I do understand people want all the CPU cycles they can for apps,
and this is of course perfectly reasonable (and thus don't take this too
seriously).
</lowprio>
On a more serious note, the key take away (especially to meego-handset
folks) is that this particular worry has very little to do with
Pulseaudio. You can do a MeeGo device without any of the abovementioned
processing, use separate DSPs, and still use Pulseaudio on top as a
frontend mixer (with very little overhead). Bypassing PA completely
should be possible as well, but then the resource framework enforcement
points need to be extended to cover the hw mixers (so that the handset
behaves as expected with regards to routing, application priority and
volume policies in effect -> you don't want "new email" tones to your
video recording, and so forth).
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Dec 20 00:15:06 2010
This archive was generated by hypermail 2.1.8 : Mon Dec 20 2010 - 00:15:07 EET