[pulseaudio-discuss] [PATCH 2/2] core: Add ARM NEON optimized sample conversion code

[Arun Raghavan]

On Thu, 2012-10-25 at 14:04 +0200, Peter Meerwald wrote:
> Hello,
> 
> > > > I was poking around this a bit. An input of 0x3f4aaa95 after the
> > > > multiplication with 32767.0 should result in 0x46caa8ff but tuns out to
> > > > be 0x46caa900. Still trying to figure out why.
> > > 
> > > I cannot follow your example, it always results in 0x46caa900 (using NEON 
> > > or not)
> 
> > (gdb) call *(float*)$3 = *(float*)$1 * *(float*)$2
> > $6 = 25940.498
> > (gdb) p /x *(int*)$3
> > $7 = 0x46caa8ff
> > This happens on both x86 and the Pandaboard.
> 
> I am curious what the correct result is for that multiplication;
> the GDB result is different from actual C code

bc suggests that it is:

  0.7916653752326965 * 32767.0 = 25940.4993502497662155

> looking at gdb's valarith.c function scalar_binop(), it appears gdb 
> performs multiplications (BINOP_MUL) as double values -- not entirely 
> sure, but I wouldn't trust gdb to produce 'accurate' results

Yup, my analysis was incorrect.	 The C code shows it turn up as 25940.5,
which your code rounds to 25941, whereas the lrint() in the C code
rounds it to 25940. The behaviour of lrint() looks odd to me, but it's
consistent on x86 and ARM. Not sure why it is so though (even lrint(0.5)
== 0).

> > Possibly we're talking about different things here -- I'm referring to
> > the float -> s16le conversion.
> 
> I've never seen deviation between NEON and C code for float -> s16le
> my claim for one-off was for s16le -> float only

You should be able to see it with the code at:
http://cgit.collabora.com/git/user/arun/pulseaudio.git/log/?h=neon-wip

-- Arun