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

[Stefan Kost]

Am 28.12.2010 00:26, schrieb Nick Copeland:
>> > 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.

Sorry for the very late reply. One thing to mention is that the CPU load for
pulse is going wown quite a bit when plugin headphones. Otherwise it runs some
extra processing needed to accomodate the speakers.

Stefan