Sandor Vegh authored 6 months ago and Jean-Marc Valin committed 2 hours ago

If the signal exceeds -1..1 then, as error handling, the soft_clip
function forces the signal back into -1..1. This is problematic since
the search loop to find the next sample exceeding -1..1 is slow.
If cheap on the current platform, while doing -2..2 hardclipping we
can also detect if the signal never exceeds -1..1, avoiding the need
for a second search loop.

Signed-off-by: Jean-Marc Valin <jeanmarcv@google.com>

Prevents integer overflow UB in the headroom left shift when
the signal blows up on bad bitstreams (if it triggers, the
signal was already unusable anyway).

valgrind does not properly handle the Denormals-Are-Zero (DAZ) flag,
which can be set by -ffast-math. That would not generally be a problem
except when the compiler implements sqrt(x) as x*rsqrt(x) with an
exception for x=0. In that case, when x is a non-zero denorm value,
the exception does not trigger with valgrind (but does on real
hardware), which causes the sqrt to evaluate to -inf instead of 0.

Sandor Zsombor Vegh authored 7 months ago and Jean-Marc Valin committed 3 weeks ago

Using Neon for float to int conversion, and introducing platform-
specific function for converting an array of float values to int16.
Also adding appropriate unit test.

Signed-off-by: Jean-Marc Valin <jeanmarcv@google.com>

Prevents integer overflow UB in the shift rounding when the signal blows
up on bad bitstreams (if it triggers, the signal was already unusable
anyway).

Not really a problem in practice (the packet is broken anyway)
but caught by asan.

Could only happen on 32-bit fixed-point builds.
The bug was introduced in 4ba06d9e.

Silences -fsanitize=unsigned-integer-overflow even though the code was
valid (not undefined) C.

Silences -fsanitize=unsigned-integer-overflow even though the code was
valid (not undefined) C.

Yunho Huh authored 4 months ago and Jean-Marc Valin committed 2 months ago

Change-Id: Ib016fc8f0066980e3e5122b3f286680adc228ff9
Signed-off-by: Jean-Marc Valin <jeanmarcv@google.com>

Yunho Huh authored 5 months ago and Jean-Marc Valin committed 2 months ago

The exp2 function was approximated using lolremez, achieving an
accuracy of less than 2*10^-7 within the range of 0 to 1.

Signed-off-by: Jean-Marc Valin <jeanmarcv@google.com>

Yunho Huh authored 4 months ago and Jean-Marc Valin committed 2 months ago

Change-Id: Ibd0d16918272cb568923d384475e139dc312c61b
Signed-off-by: Jean-Marc Valin <jeanmarcv@google.com>

Yunho Huh authored 5 months ago and Jean-Marc Valin committed 2 months ago

The log2 function was approximated using lolremez, achieving an
accuracy of less than 1.4*10^-8 within the range of 1 to 2.

Signed-off-by: Jean-Marc Valin <jeanmarcv@google.com>