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

The CPU load for pulseaudio does not appear to change much with sampling
rate, taking 24kHz, 48kHz gives a very similar profile but you mention a bug
report that notes that fact anyway. Bristol does have a very different footprint
depending on sampling rate and filter selection.

The code will attempt to set the CPU freq to 600MHz when it starts, it does
not necessarily need these cycles but it helps to reduce underruns. Pulse
now rolls along at about 8% to 10% CPU for any rates I have tried and bristol
will take about 8% at 24kHz and double that (17%) for 48kHz.

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

This refers to the same data as above, ie, the resampling algorithm is not
where the CPU cycles are being spent. The report discusses the same results
as above but comparing 44.1kHz to 48kHz.
 
> 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).

It is sometimes difficult to understand the added value of a given process.
My first reply noted the fact that a complete synth voice with osc/mix/fil/env
and all its internal processing overhead had a lower footprint than the audio
daemon. It is easy to fall into 'Sendmail Syndrome' implying that the process
takes a lot of time, effort (in sendmails case configuration as well) whilst
not evidently bringing much to the table.

I was actually pleasantly surprised by how well the N900 managed to support
the app, the 8/16 percent CPU footprint is better than I was anticipating for
all the floating point activity here and in truth pulseaudio is also showing that
same rough load profile with respect to the two very different systems.

The point you make in your email is that pulse is bringing features to the table
here and that they invariably come with some cost. It doesn't appear that it is
unexpected load though.

If anybody wants to test bristol on the Maemo/N900 it can be found here:

http://sourceforge.net/projects/bristol/files/bristol/0.60/bristol-0.60.8.deb.tar.gz/download
http://bristol.sourceforge.net/news.html

There are notes in the news page regarding how to install the .deb, you need
root access installed for the dpkg and as the file had to be tarred and gzipped
to be accepted by sfdc you have a couple of extra steps either on the phone
or on your PC prior to the install.

Kind regards, nick