[pulseaudio-discuss] [Ubuntu-audio-dev] Preferred resampler method on armhf.

[Alexander E. Patrakov]

20.11.2014 15:58, David Henningsson wrote:
>
>
> On 2014-11-20 08:40, Alexander E. Patrakov wrote:
>> 20.11.2014 12:35, David Henningsson wrote:
>>> Crossposting to Debian and upstream lists.
>>>
>>> Apparently Debian has a patch that uses fixed point by default on armhf,
>>> so I'm just echoing Luke's question here: Has anybody performed any
>>> testing or benchmarks across armhf hardware, w r t fixed point vs
>>> floating point resampling with speex and PulseAudio?
>>
>> That patch has been superseded by this commit:
>>
>> http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=ac984f59d36ef555bc5b0df9af1cd48193d0d14f
>>
>>
>>
>> So, if you prefer a fixed-point resampler on armhf (or, for that matter,
>> on any other architecture), just compile speex with --enable-fixed-point
>> there.
>
> Well, this is a more of an "upstream default" question rather than a
> "why don't you recompile speex" question, and one where it might make
> sense to come up with something reasonable across the board; either by
> upstreaming "fixed point by default for armhf", or by Debian to drop its
> patch.
>
> It does not look likely to me that PulseAudio upstream and Debian would
> correspond to so different machine/user scenarios so that a Debian
> specific patch would make sense here.

Indeed, a Debian-specific patch does not make sense.

But, even before my patch, and assuming that someone wrote a different 
solution to the bug that led to it, why would they want to default to 
speex-float-X on a fixed-point speex, or to speex-fixed-X on a 
floating-point speex library? Look, the first thing this resampler does 
is to convert the samples into its preferred representation, possibly 
undoing the conversion done by PulseAudio.

Ideally, the distinction between speex-float-X and speex-fixed-X 
resamplers should be completely killed in PulseAudio, exactly because 
PulseAudio converts between these forms faster than speex does internally.

-- 
Alexander E. Patrakov