| Age | Commit message (Collapse) | Author |
|---|
|
This leak appears only when using a custom destroy callback (set via the
JITTER_BUFFER_SET_DESTROY_CALLBACK ctl message).
In order to understand how this happens, the following information needs
to be known:
- The jitter buffer implementation always overwrites a freed pointer
with NULL and therefore can check for NULL in order to determine if a
given packet's data buffer has been freed already.
- When accessing the data in the buffer from the outside, you'll get a
copy of the data when NOT using a custom destroy callback but simply a
copy of the pointer to the original buffer, when using a custom destroy
callback.
Because of the latter, the query methods can't immediately free the
original data buffer if a custom delete callback is used, as the
returned pointer has to remain valid. In the other case (no custom
callback), the data is freed immediately after it has been copied.
The issue arises, because the data-pointer in the internal packet
structure is UNCONDITIONALLY (aka: regardless of whether a custom
callback is used or not) overwritten by NULL, indicating to all
following code that the data buffer has been freed already. However, as
described above this is not the case, if a custom destroy callback is
used.
Therefore, the data buffer will never be freed in that case (unless the
calling code deletes the data itself. However, as there is no
documentation that implies otherwise, it seems a fair assumption on the
caller's site that the buffer will handle the lifetime of the data
buffer even if a custom destroy callback has been registered. Therefore,
the calling code wouldn't actually perform the freeing) causing a memory
leak.
This commit fixes this issue simply by making sure to not overwrite the
data pointer with NULL, in case a custom destroy callback is used.
Therefore, the data pointer is only set to NULL, when it is actually
freed and otherwise the follow-up code inside the jitter buffer will
know that the buffer hasn't been freed yet and can act accordingly.
|
|
Signed-off-by: Tristan Matthews <tmatth@videolan.org>
|
|
|
|
This was added in
https://gitlab.xiph.org/xiph/speexdsp/-/commit/0dd7bfebe55abcac7e9acbca9d2ac2eddeee2b6f#5424d940076d3b85a3fc2d9f2dcf0d905c43abf0_466_472
to address truncation reported at
http://lists.xiph.org/pipermail/speex-dev/2009-June/007277.html
Truncation of the most-signficant bit was occuring on conversion to
spx_word16_t in MULT16_32_Q15(). Changes to MULT16_32_Q15() mean this will no
longer occur.
The associated adjustment to the bit-shift before saturation was accidentally
removed in
https://gitlab.xiph.org/xiph/speexdsp/-/commit/0e5d424fdba2fd1c132428da38add0c0845b4178#6479ffd77de750bc70cf92af3f9b8a4c1e15a98a_473_478
which caused the output to have half the intended amplitude when the
interpolating resampler was used.
Reported by Andreas Pehrson.
|
|
The 32-bit arg and return value have one bit more than required to represent
+/-32767 with 15 fractional bits.
Keeping the most significant bit allows saturation for 16-bit conversion to
sometimes be delayed until after these operations.
|
|
|
|
This is largely based off of speex's.
|
|
|
|
Signed-off-by: Tristan Matthews <tmatth@videolan.org>
|
|
Signed-off-by: Tristan Matthews <tmatth@videolan.org>
|
|
Reported by Mark Harris
|
|
- Do not define macros, functions, or variables with file scope using
names beginning with an underscore (these names are reserved for the
implementation; see C89 section 7.1.3 or any later version) or that
shadow other global declarations
- Avoid declarations after statements (speex_assert) for C89 compat
- Silence unused parameter warning in resampler_basic_zero
- No need for the stack_alloc.h macros within #ifdef VAR_ARRAYS; use
the standard C syntax
- When OUTSIDE_SPEEX, define EXPORT if not already defined
- Update URL to https
|
|
port optimized inner_product_single and WORD2INT(x) for fixed
and floating point from 32 bit armv7 NEON to aarch64 NEON.
|
|
|
|
Unbreaks --enable-neon
|
|
|
|
Minor fix to delete a single unused variable
Signed-off-by: Tristan Matthews <tmatth@videolan.org>
|
|
|
|
Add checks to avoid den_rate and num_rate to be set to 0.
Change-Id: Ia4880521e7ab73d0fdc44377f4badadb09365471
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Signed-off-by: Dario Lombardo <lomato@gmail.com>
Signed-off-by: Tristan Matthews <tmatth@videolan.org>
|
|
|
|
|
|
Reported on Opus mailing list, see:
http://lists.xiph.org/pipermail/opus/2016-July/003591.html
|
|
Fix regression from commit 4dba09347256131f12c80b443250abae4bbbe042
Reported by Lukáš Lalinský.
|
|
speex_alloc already sets these arrays to 0.
Reported by Jean-Yves Avenard <jyavenard@mozilla.com>
|
|
|
|
From bugzilla.mozilla.org bug #1266260
Signed-off-by: Tristan Matthews <tmatth@videolan.org>
|
|
Signed-off-by: Tristan Matthews <tmatth@videolan.org>
|
|
Add a test that resamples a sine wave with varying samplerates to create
a sweep.
Signed-off-by: Tristan Matthews <tmatth@videolan.org>
|
|
Make sure we don't overflow when calculating the phase for the new
sample rate.
Signed-off-by: Tristan Matthews <tmatth@videolan.org>
|
|
Use Euclids algorithm to calculate the greatest common divisor to
simplify the resample ratio fraction instead of the slow iterative
method.
Signed-off-by: Tristan Matthews <tmatth@videolan.org>
|
|
This isn't needed (and isn't doing anything here anyway).
|
|
Not everyone who includes speexdsp_config_types.h will have a test
which defines those, and if we've chosen to use the stdint types at
configure time then we know exactly which header(s) are available, so
just choose the best one then and generate the header to use it.
This patch, including the above text, is copied from a commit in the
speex repository[1]. The original commit for speex was made by Ron
<ron@debian.org>.
[1] https://git.xiph.org/?p=speex.git;a=commitdiff;h=774c87d6cb7dd8dabdd17677fc6da753ecf4aa87
Signed-off-by: Tanu Kaskinen <tanu.kaskinen@linux.intel.com>
|
|
Reported-by: Fabian Henze <flyser42@gmx.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
_USE_SSE2 was only being defined for win32 builds on x86-64
|
