10.05.2014 23:12, Peter Meerwald wrote: > Hi, > >>>> When Speex is compiled with FIXED_POINT defined, it scales float input >>>> to ?32768 instead of ?1. In order to make floating point resampler >>>> work with speex compiled with FIXED_POINT, we need to rescale the input >>>> to speex. This rescaling does not hurt normal speex, so we do it >>>> unconditionally. >>> >>> floating point multiplication is quite costly on some platforms, I'd >>> rather not force everyone to scale every sample twice for no good reason >> >> Well, on such platforms (*cough* ARM *cough*) I'd call it a bug to use >> speex-float-* resamplers by default, or even to provide them at all. If we fix >> that, then the extra multiplication in an already-very-slow path would no >> longer be relevant. > > speex-float resampler is actually faster than speex-fixed when using the > NEON patch, or at least on par -- so it depends > > but floating point math really sucks on Cortex-A8, doing the same > operation with NEON is quite fast Do I understand correctly that the above is a consideration on how one should build speex on various ARM platforms? > so how about overriding PA's speex-float choice to speex-fixed when we > find that speex-float is compiled as FIXED_POINT (and educate the user?) Good idea, but it would be really nice to see the numbers. Especially the following comparison. Compile Speex as appropriate for the target platform. Start from s16 samples, as found on a CD. Variant A: convert them to floating point in PulseAudio, feed to speex_resampler_process_float(), convert back to s16. Variant B: feed directly to speex_resampler_process_int(). I.e. do not compare the two variants of speex, but two ways of using the optimally-compiled speex. I am going to extend this thought in another e-mail. -- Alexander E. Patrakov
