[pulseaudio-discuss] [PATCH] core: Fix a litte-endian bug in ARM svolume code

[Arun Raghavan]

On Mon, 2012-10-22 at 15:19 +0200, Peter Meerwald wrote:
> 
> > > checking NEON volume_float32ne
> > > NEON: 10223 usec.
> > > ref: 46480 usec.
> > > checking NEON volume_s16ne
> > > NEON: 8484 usec.
> > > ARM: 339272 usec.
> > > ref: 20203 usec.
> > 
> > That's odd indeed. I have this on a Freescale i.mx53 (also Cortex A8)
> > 
> > Checking ARM svolume
> > func: 905150 usec (min = 9006, max = 9562, stddev = 76.1938).
> > orig: 2278824 usec (min = 22760, max = 23252, stddev = 65.5575).
> > 
> > Any chance you could rerun this?
> 
> # ./cpu-test 
> Running suite(s): CPU
> CPU flags: V6 V7 VFP EDSP NEON VFPV3 Cortex-A8 
> Initialising ARM optimized volume functions.
> Checking ARM svolume
> 0: 1ac8 != 390e (43e9 * 0000d716)
> Orc not supported. Skipping
> 50%: Checks: 2, Failures: 1, Errors: 0
> tests/cpu-test.c:52:F:svolume:svolume_arm_test:0: Failed
> 
> hmm... fails every time

Does this include the little-endianness fix?

> sorry for the late reply on this
> 
> shall I try to move NEON test code to cpu-test or are you going to do 
> this?

Don't bother for now, let's get all the other bits sorted out first.

My current testing shows NEON svolume code with int16 samples
consistently slower than the ARM code (tried on the Pandaboard, i.mx51,
i,mx53, imx.6) by ~10% in most cases.

Starting to look at the other bits now as well.

Cheers,
Arun