Both versions of silk/tables_NLSF_CB had symbols
named silk_NLSF_CB1_Wght_Q9 which causes problems
if both files are build as part of the same
compilation unit. Rename the wideband version
to include a 'WB' string to avoid the conflict.

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>

This was sometimes causing the music probability to be stuck at
zero at the beginning of files

Jonathan Lennox authored 7 years ago and Timothy B. Terriberry committed 7 years ago

It's unnecessary, and isn't defined correctly on floating-point.

This makes us correctly use Neon functions (in floating-point mode) on
platforms where Neon is detected by RTCD.

Signed-off-by: Timothy B. Terriberry <tterribe@xiph.org>

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

Now scaling the energy to the same value is would be in floating-point

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

Thanks to petrufm for pointing that out:
https://github.com/xiph/opus/issues/35

This makes it possible to run the testvectors with asan enabled.

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

Ricardo Constantino authored 7 years ago and Ralph Giles committed 7 years ago

And run the build request only at the last configuration.
Also add a check if api_key is unset to not try to request a new build.

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

The appveyor script needs an encrypted api key to trigger
downstream builds, and there doesn't seem to be an easy
way to make the builds we run for the main repo something
other contributors can control.

Signed-off-by: Ricardo Constantino <wiiaboo@gmail.com>

Ricardo Constantino authored 8 years ago and Ralph Giles committed 7 years ago

Using my API key for now, but needs rillian's to work.

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

Ricardo Constantino authored 8 years ago and Ralph Giles committed 7 years ago

Artifact with preserved paths is more useful for CI.

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

Ricardo Constantino authored 8 years ago and Ralph Giles committed 7 years ago

Less clutter on systems that hide dotfiles.

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

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

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

Change-Id: I607a8b75b0711a485384d6f854cf6e2ec18b38b7

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

The constant was copied from the analysis code which uses +/-1 as float
scaling, but surround_analysis() uses +/-32767.

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

The optimization is bit exact with C function.

Change-Id: Ifb8f04b19f2d576e79ce5dcfa7e0fc374d71d6c8

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

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

Split to silk_biquad_alt_stride1() and silk_biquad_alt_stride2(),
so that it can be optimized more efficiently when stride is 2.

This change in C code is bit exact with the origin.

Change-Id: Idaefe670397016ace2a489e3435ac61b7dbe79d5

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

Makes things a little easier to read.

Signed-off-by: Gian-Carlo Pascutto <gcp@sjeng.org>

Make it easier for users unfamiliar with C applications
to installed the necessary build dependencies.

Signed-off-by: Gian-Carlo Pascutto <gcp@sjeng.org>

Carlos Alberto Lopez Perez authored 8 years ago and Ralph Giles committed 7 years ago

This fixes an issue with gcc 4.9 on Debian 8, at least,
which defines __STDC__ but not __STDC_VERSION__, unlike
more recent gcc.

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

Drew Allen authored 7 years ago and Jean-Marc Valin committed 7 years ago

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