On Thu, 2012-10-25 at 10:19 +0200, Peter Meerwald wrote: > Hello, > > > > > conversion may be off by one for some samples due to rounding issues > > > > > > I'm not sure about the impact of this. Is there no way to avoid the > > > rounding error? > > > > Thinking about it some more, I think having sconv be exactly the same > > across implementations is important. Is this some sort of NEON quirk? > > >From what I can tell, the result of the vmul is off-by-one. > > I'll have a closer look, certainly interesting; not sure how relevant -- > generally don't use floating point if you expect exact results > > on a similar note, I have never checked that floating point speex > resampling is sample-exact across platforms/optimization settings 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. -- Arun