<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
> so as mentioned in other replies, this is not really pulseaudio to blame. <br>> On N900 there is some fixed processing that must be applied to all streams <br>> (and there are different pipelines for different uses and routes, so it's <br>> not always constant). With N900 this code is now in PA (as it's the system <br>> mixer, there's no hw mixer under the hood). The load is smaller e.g. when <br>> you use earpiece/headset (versus speaker), and also it should be lower if <br>> you have the apps use the hw rate (48kHz in N900 case). You can challenge <br>> the N900 design, but none of this is really specific to Pulseaudio.<br>[snip}<br><br>That was a very interesting post, will be keeping it. Now PA does use quite<br>a lot of CPU on the N900 - the +/-2% it requires on my laptop translates into <br>about 25% on Maemo, this really is quite an overhead and as far as I can tell<br>it does not change with sampling rate (I get the same overhead with 48kHz<br>as with 44.1kHz although I will retest that).<br><br>I am assuming, possibly incorrectly, that it uses Lennart's correct resampling<br>algorithm. Is this the case? If so is there any way an application can request <br>an alternative? To get bristol to work on the N900 without gobbling up masses<br>of CPU required large period sizes, relatively large preloading of buffers with <br>added latency, downsampling to 24kHz, no resampling filters. The last two <br>reduce the audio quality but prevent it from guzzling battery like there were <br>no tomorrow. If PA is still using the intense resampling to maintain quality <br>then there is an issue here - there would be no point is quality resampling as <br>the signal has already been degraded.<br><br>Regards, nick.<br> </body>
</html>