[LAD] Meego pulseaudio "compliance" and "enforcement" (was Re: [Meego-handset] Enabling Speakerphone)

[Kai Vehmanen]

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).