[pulseaudio-discuss] [PATCH v2] resampler: Support speex resampler compiled with FIXED_POINT

[Alexander E. Patrakov]

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