On Mon, 2012-02-20 at 09:41 +0100, Peter Meerwald wrote: > Hello, > > > http://pulseaudio.org/wiki/ReleasePlanning > > Fixed resamplers [Pierre-Louis Bossart] > > what is the task here? > does that include the SSE3 resampler? > what is supposed to work, what not? Yes, this is the SSSE3 resampler. This is meant to use the fixed-rate resampler for supported rates and fallback to the automatic mode for others. As you might've seen, we've deferred merging this for now. Getting NEON support here too would be very cool, though. > NEON sconv/mixing [Peter Meerwald] > > I plan to submit an updated patch series soon; a NEON remap_stereo_to_mono > will be added, I'm wrestling with gcc ICEs > > an open issue is build system support for different optimizations, a clear > strategy would be nice -- Arun? > > sbc_primitive_neon checks for NEON compiler support, but no runtime checks > > elsewhere inline assembly is used with runtime checks, but no compile-time > checks/configure options > > what is missing is probing at compile-time and translation of files with > different optimization/architecture flags > > the simple solution for my NEON patches now would be to mimic the > sbc_primitive_neon way... I'm going to give your patches a review and test cycle today if I can. I'll also mull over how to handle the build system side of things here. > More Orc [Maarten Bosmans] > > Orc is not enabled for ARM at the moment; svolume-orc breaks on ARM NEON > as loadpq does not compile I did try svolume-orc on NEON. It worked a few months ago but was much slower, because ARM has a single instruction to do what all the 32x16 code does. I'd spoken to David Schleef a while back about this and he'd mentioned that he's open to making an Orc instruction for this that generates something like what we already have for x86 and just the single instruction (maybe there's a NEON version of it too?) on ARM. > ad Alternate sample rates: > > this does not work for me on a beagle-xm -- PA fails to wake up after > suspending; it works if I set both alternatives to the same sample rate; > maybe this is related to --system mode > > anyone interested in log messages? The only ARM device I've run this on is an OMAP4 which seems to do only 48kHz. Logs are certainly welcome. Could this be a driver issue? -- Arun
