[pulseaudio-discuss] Re : Effects of Clock Resolution on Pulseaudio

[Nick Thompson]

On Jul 30, 2008, at 12:08 PM, Lennart Poettering wrote:

> On Tue, 22.07.08 17:13, Nick Thompson (rextanka at comcast.net) wrote:
>
>>>> So i am not sure what part of Pulseaudio is causing high CPU  
>>>> Utilization
>>>> ..
>>>
>>> Hmm, could you do some profiling then? Just the most basic. I.e.  
>>> what
>>> functions take up most CPU.
>>
>> I'll add more detail in a bit when we get to 0.9.10, h  
>> pa_volume_memchunk
>> seems to be a big hitter on arm systems:
>
> Hmm, that function is not optimized in any way, but if I look on its
> sources doesn't appear that slow to me either. For each sample we do
> one multiplication, one shifting, we appy saturation and then we
> increase/decrease poinetrs with wrap around. That shouldn't be that
> bad. Also, this code goes once linearly through all samples, which  
> should
> minimize influence of the cache.

Yeah the problem seems to be that ARM has a limited number of  
registers and gcc does not deal with monolithic code that well, where  
as x86 will have no issues in dealing with a large case statement with  
a number of loops in it.  A look at the gcc output indicated a number  
of load instrs in the loop which is very expensive on ARM (3 cycles).   
A co-worker has been working on some arm assembly and factoring the  
loops out into separate functions, and the net result of this is that  
we see 4-6% total, which is much better.  We need to look at the mix  
and rate convert cases too, the mix is more complicated but we should  
see something similar there.

Also I want to look at Kevin's emails and see if we can build on that,  
it would be good to get that working on a couple systems.

Patches will be forthcoming for this, however we are still on 0.9.8, I  
am hoping we'll have made the move to 0.9.10 this week, so I hope we  
can send you stuff in a couple weeks once we are happy they are tested  
well.  The patches will be for 0.9.10 so help in getting that merged  
with the latest would be handy, though I'd suspect these routines are  
not so much in flux at the moment?

> I assume the data processes is S16NE and the CPU is LE?

Yup.  That's the path we started with the optimization.

> Hmm, can you figure out in which context this is called that often? (i
> mean, pa's audio memory management should be mostly zero-copy, so
> having such a big hit on memcpy here is surprising to me.
>
>>> 277       3.5951  libm-2.5.so              __adddf3
>
> This is interesting, could you figure out the context?

Yup, I need to patch our kernel again to get call trace with oprofile  
on my device, so hopefully I can find some time to get context for this.

With regards to the vectorization stuff, that can be used, although it  
would make the arm code very specific to a certain subset of ARM  
implementations.  It brings a philosophical question, since I'd  
suspect a generic ARM implementation is a better open source solution,  
having the optimized cases for cortex-a8/NEON processors would be  
useful, but it would add to the build complexity, and potentially  
would be frustrating for someone with a different ARM processor.  I'm  
not sure I understand open source well enough to decide this.  That  
being said we'll probably optimize for our case and that any patches  
will likely be somewhat system dependent.  Worst case is it gives  
someone else something to build on, I guess.

Regards

Nick