Bug#799176:

[Erik Montnemery]

〉A better report would have just pointed directly to the commit(s) in the
〉upstream repo that you thought were relevant to this.

Alright, this is the relevant commit:
http://git.xiph.org/?p=speexdsp.git;a=commitdiff;h=0e5d424fdba2fd1c132428da38add0c0845b4178

>It's a bit of a stretch to call something "completely broken" when there's
>a huge number of existing users who haven't hit this problem over the last
>like, 8 years or so (and possibly even longer since the resampler code had
>changed in any way relevant to this).  That kind of naturally precludes an
>"everybody panic and kick it out of testing" severity ...
Yeah, it's really strange. I did some searching, but couldn't find any
other complaints about overflow. I'm not resampling between any exotic
sample rates either, I get the problem when ALSA is upsamling from
44.1kHz to 48kHz.
It IS of course depending on the source though, I first noticed the
problem when listening to some highly compressed (as in dynamic
range), bass driven music with (supposedly) no attenuation in the
audio path before the resampler.

>Updating this has become slightly more complicated since the speexdsp code
>has now been split out of speex as a separate source, and I haven't been
>in a hurry to introduce a potential disruption like that until the timing
>for that was good and the need for it compelling - but this bug at least
>qualifies the latter requirement, so I'll bump making that happen up the
>list to suit.
Alright, sounds great!
Maybe just backporting the commit is a good first step if it's a lot of work?
At the same time, it would be great if the armhf was allowed to use
the fp implementation.


Thanks,
Erik