On Thu, Jul 31, 2008 at 12:30:15AM +0200, Lennart Poettering wrote: > On Wed, 30.07.08 15:00, Nick Thompson (rextanka at comcast.net) wrote: > > 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? Marvell Xscale processor family provides some SSE-like instructions, and others ARM vendor may have different solution on SIMD and vector. I think a generic ARM implementation is better for open source, as Nick said. On the other hand, it is great to have some plugin interfaces for users to insert their own resampler and mixing functions. The ARM vendor usually provides some optimized functions based on their architecture. So I like the resampler implementation very well, and I could insert my routines to replace the one in PA. -- Stanley Cai Gtalk: stanley.w.cai at gmail.com GnuPG: 0x86A5B367
