Bug#799176:

[Ron]

On Sat, Sep 19, 2015 at 04:29:04PM +0200, Erik Montnemery wrote:
> > 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

Yes, I already searched the outstanding changes for that :)

"resample: Add NEON optimized inner_product_single for fixed point"
doesn't exactly scream "this fixes a rare overflow in unoptimised code"
at first glance, but there's also a few other changes in that set we'll
want now too.

> >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.

It's not particularly strange, if you're going to do just about any sort
of DSP on loudness war samples without attenuating them to gain some
headroom first, they *are* going to be distorted.

This patch still doesn't stop them from being distorted either - it just
changes the distortion from integer wraparound to hard clipping.

The real answer for samples like that, independently of how they are
handled in any part of the audio chain, *is* to dial down the gain on
them.

> >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?

There's no point doing a half-assed job of this, but it's a potentially
disruptive change so it needs more care than an ordinary update.

> At the same time, it would be great if the armhf was allowed to use
> the fp implementation.

Why?  Having an FPU doesn't magically make it the most efficient way to
do things on any given architecture.


  Ron