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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
