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

[Lennart Poettering]

On Wed, 30.07.08 15:00, Nick Thompson (rextanka at comcast.net) wrote:

> 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?

Nope, except for optimization patches I see not much changing in this
code.

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

We can always #ifdef things for specific processors. 

I am interested in SSE support for x86, for that stuff I'd probably
ship multiple compiled version of at least some parts of libpulsecore
which are then loaded dynamically depending on what features the CPU
has. glibc actually contains support for this already for some cpu
features (tls, and sse I think), and I would assume something similar
is available for ARM too?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4