Roman Kalashnikov authored 7 years ago and Ralph Giles committed 7 years ago

Fixes a warning from PVS-Studio. This was a cut-and-paste error
from the stanza above and had no effect.

Signed-off-by: Ralph Giles <giles@thaumas.net>

Addresses issue https://github.com/xiph/opus/issues/54

Addresses issue https://github.com/xiph/opus/issues/58

Reported in https://github.com/xiph/opus/issues/55

The regression was introduced in 783ad767
by changes to celt_fir() that make it no longer in-place.

Based on two dense layers with a GRU layer in the middle

Make these consistent with the other optimization file
sets which use a suffix to indicate the extension they
use.

Signed-off-by: Jonathan Lennox <jonathan@vidyo.com>

Distinguish source files for the SSE 4.1 instruction
set extension consistently by their filename. This makes
it easier to check the correct flags are being set at
build time.

Signed-off-by: Jonathan Lennox <jonathan@vidyo.com>

Ray Essick authored 7 years ago and Felicia Lim committed 7 years ago

some SSE optimizations were using an instruction sequence that required
128-bit alignment, even though this is not always guaranteed. The error
was in handling a 64-bit entity; made the same macro changes that had
been done previously for 32-bit entities.

Signed-off-by: Felicia Lim <flim@google.com>

Linfeng Zhang authored 7 years ago and Jean-Marc Valin committed 7 years ago

This bug is introduced in commit 85fb8a1d.

Change-Id: I3822cdfc1308ca62ce03da008260de8f4b04596c

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Linfeng Zhang authored 8 years ago and Jean-Marc Valin committed 7 years ago

Call celt_inner_prod_neon() and remove redundant code.

Change-Id: I980e94330ae75c10297b9035fac221515aee144f

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Linfeng Zhang authored 8 years ago and Jean-Marc Valin committed 7 years ago

The floating-point optimizations are not bit exact with C functions,
because of the different orders of floating-point operations.
But they are bit exact with the simulation C functions which simulate
the floating operations in the optimizations.

Change-Id: I149fda5b602fd5712b16fc8983df3c6c0c9e76ad

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Linfeng Zhang authored 8 years ago and Jean-Marc Valin committed 7 years ago

This optimization is bit exact with C functions.

Change-Id: Ia9ce6dd3c20d2f56dbd43ddc02d1a6fd6554608d

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Linfeng Zhang authored 8 years ago and Jean-Marc Valin committed 7 years ago

Should call celt_inner_prod().
This requires the API change of celt_pitch_xcorr() by passing in
"arch".

We tested on x86 and arm, and got bit exact results as original.

Change-Id: I606915da6a196f327ce81f4a5ae32811f4c1fabb

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Linfeng Zhang authored 8 years ago and Jean-Marc Valin committed 7 years ago

Should call celt_inner_prod().

This change is bit exact as original, except for x86 floating-point.
In x86 floating-point, it calls celt_inner_prod_sse() which may have
different output with the change of floating-point operations' orders.

Change-Id: Ia2381e2e198a84296ac28305183f15be842b3454

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

We boost bands that either cause leakage or are filled with leakage

It seems like letting CBR use up to 2/3 of the bit is still a win

We now include the object files for those rather than attempt to
problems.

The code would have run fine on 32-bit archs, but would have overflowed
on a 16-bit arch

Some informal tests seem to confirm that reducing the trim at 32-64 kbps
improves quality (better HF). It's not clear whether it's also the case
at 96 kb/s and above, so we're leaving it as is for those rates.

This corresponds to buildC in this thread:
https://hydrogenaud.io/index.php/topic,113985.0.html

Also see:
https://hydrogenaud.io/index.php/topic,111798.0.html

- celt/modes.c:430:14: warning: cast from 'const unsigned char *' to
  'opus_int16 *' increases required alignment from 1 to 2 [-Wcast-align]
- 'C[0][1]' may be used uninitialized [-Wmaybe-uninitialized]
- Unused variable/parameter
- Value stored is never read
- MSVC warnings about "possible loss of data" due to type conversions
- MSVC warning C4146: unary minus operator applied to unsigned type
- silk/NLSF_del_dec_quant.c:137:20: warning: array subscript is above
  array bounds [-Warray-bounds] (gcc -O3 false positive)
- src/mlp_train.h:39:20: warning: function declaration isn't a prototype
  [-Wstrict-prototypes]
- Remove SMALL_FOOTPRINT code from SSE 4.1 FIR implementation, matching
  the C implementation.

The clang -Wcast-align warnings with SSE intrinsics are a known
clang issue: https://llvm.org/bugs/show_bug.cgi?id=20670

Wasn't worth it given the small code size of the alternative, which also
got refactored a little (still bit exact).

Cannot prove it's the correct value, but it's better than the previous
values, which sometimes segfaults. The increase was made necessary due
to 120 ms frame size support.

Michael Bradshaw authored 8 years ago and Jean-Marc Valin committed 8 years ago

libopus only uses the DSP module of Ne10, and never uses the init functions.

Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Michael Bradshaw authored 8 years ago and Jean-Marc Valin committed 8 years ago

Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

Broken by 76e831d9.  Without the .type directive, SIGILL may be produced
if the C code is compiled in Thumb mode, because the compiler may assume
that the asm symbol is also Thumb and call it using a BL instruction.

Casting to unsigned to avoid shifting negative values left.

Linfeng Zhang authored 8 years ago and Felicia Lim committed 8 years ago

The "mem" in celt_fir_c() either is contained in the head of input "x"
in reverse order already, or can be easily attached to the head of "x"
before calling the function. Removing argument "mem" can eliminate the
redundant buffer copies inside.
Update celt_fir_sse4_1() accordingly.

James Zern authored 8 years ago and Jean-Marc Valin committed 8 years ago

this has the side-effect of removing some C++ style comments

Signed-off-by: Jean-Marc Valin <jmvalin@jmvalin.ca>

This could happen when we had more than 32 bits on the first hybrid band with
a transient just in the middle of the frame. The band would be split and the
first half of the frame could end up with non-zero energy, but not enough
bits for a pulse. Because it's the first band, no folding would be possible.
This would cause noise to be injected for the entire duration of the first
half and that noise should then get folded to higher bands.

The change also makes the analysis run for sampling rates of 16 kHz and 24 kHz
since the features are only computed on the 0-8 kHz band. The longer time
window (20 ms instead of 10 ms) makes the tonality estimator more reliable
for low-pitch harmonics.

That experiment never actually worked

We now try not to fold below band 17 since that produces a lot of harshness.
This mostly helps around 32-40 kb/s.