〉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
