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

[Nick Copeland]

> so as mentioned in other replies, this is not really pulseaudio to blame. 
> On N900 there is some fixed processing that must be applied to all streams 
> (and there are different pipelines for different uses and routes, so it's 
> not always constant). With N900 this code is now in PA (as it's the system 
> mixer, there's no hw mixer under the hood). The load is smaller e.g. when 
> you use earpiece/headset (versus speaker), and also it should be lower if 
> you have the apps use the hw rate (48kHz in N900 case). You can challenge 
> the N900 design, but none of this is really specific to Pulseaudio.
[snip}

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

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 
an alternative? To get bristol to work on the N900 without gobbling up masses
of CPU required large period sizes, relatively large preloading of buffers with 
added latency, downsampling to 24kHz, no resampling filters. The last two 
reduce the audio quality but prevent it from guzzling battery like there were 
no tomorrow. If PA is still using the intense resampling to maintain quality 
then there is an issue here - there would be no point is quality resampling as 
the signal has already been degraded.

Regards, nick.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20101219/c7dcd714/attachment.html>