<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
> > Now PA does use <br>> > quite a lot of CPU on the N900 - the +/-2% it requires on my laptop <br>> > translates into about 25% on Maemo, this really is quite an overhead and <br>> > as far as I can tell it does not change with sampling rate (I get the <br>> > same overhead with 48kHz as with 44.1kHz although I will retest that).<br>> <br>> btw, one thing to watch out when doing measurements is the CPU <br>> frequency... N900 uses very aggressive cpufreq and even with heavy audio <br>> processing, the CPU is not necessarily running at full speed (so even if <br>> top shows 25%, that doesn't necessarily mean that only 75% processing <br>> capacity is left for apps). But this is really only a problem when making <br>> measurements (the cpufreq is boosted automatically when needed).<br><br>The CPU load for pulseaudio does not appear to change much with sampling<br>rate, taking 24kHz, 48kHz gives a very similar profile but you mention a bug<br>report that notes that fact anyway. Bristol does have a very different footprint<br>depending on sampling rate and filter selection.<br><br>The code will attempt to set the CPU freq to 600MHz when it starts, it does <br>not necessarily need these cycles but it helps to reduce underruns. Pulse <br>now rolls along at about 8% to 10% CPU for any rates I have tried and bristol<br>will take about 8% at 24kHz and double that (17%) for 48kHz.<br><br>> There should be no resampling happening (if you use 48kHz), so it<br>> should not be that. But if src is used in your case, N900 uses speex src <br>> (speex-fixed-2) optimized for arm NEON (see Siarhei's comment in bug for<br>> info and links:<br>> https://test.maemo.org/testzilla/show_bug.cgi?id=5794#c10 ).<br><br>This refers to the same data as above, ie, the resampling algorithm is not <br>where the CPU cycles are being spent. The report discusses the same results<br>as above but comparing 44.1kHz to 48kHz.<br> <br>> Don't take this too seriously, but I've personally found it a bit <br>> suprising how much negative feedback there has been about the audio mixer <br>> CPU cycles. In phones (versus desktop/laptops), some processing is needed <br>> as audio quality (especially for voice calls) is a closely followed aspect <br>> (it is benchmarked by various parties and various organizations have <br>> detailed requirements concerning it).<br><br>It is sometimes difficult to understand the added value of a given process. <br>My first reply noted the fact that a complete synth voice with osc/mix/fil/env<br>and all its internal processing overhead had a lower footprint than the audio<br>daemon. It is easy to fall into 'Sendmail Syndrome' implying that the process<br>takes a lot of time, effort (in sendmails case configuration as well) whilst<br>not evidently bringing much to the table.<br><br>I was actually pleasantly surprised by how well the N900 managed to support<br>the app, the 8/16 percent CPU footprint is better than I was anticipating for<br>all the floating point activity here and in truth pulseaudio is also showing that<br>same rough load profile with respect to the two very different systems.<br><br>The point you make in your email is that pulse is bringing features to the table<br>here and that they invariably come with some cost. It doesn't appear that it is<br>unexpected load though.<br><br>If anybody wants to test bristol on the Maemo/N900 it can be found here:<br><br>http://sourceforge.net/projects/bristol/files/bristol/0.60/bristol-0.60.8.deb.tar.gz/download<br>http://bristol.sourceforge.net/news.html<br><br>There are notes in the news page regarding how to install the .deb, you need <br>root access installed for the dpkg and as the file had to be tarred and gzipped<br>to be accepted by sfdc you have a couple of extra steps either on the phone<br>or on your PC prior to the install.<br><br>Kind regards, nick<br><br> </body>
</html>