I've been reading some examples of how to work with this library and for what it seems to be, it looks like we know the input length but we have to guess the output length. Am I correct? Or is it just a "read until there's no more" where I should process the input until there is no more samples to be read? https://github.com/xiph/speexdsp/blob/master/libspeexdsp/testresample2.c#L71

Thank you in advance!

Due to build error (math library non-conformance), the project can't be built on certain platforms/IDE's. For this issue report i reproduced it using Visual Studio 2022 17.10.

The error:

speexdsp\libspeexdsp\testresample2.c(57,43): error C2065: 'M_PI': undeclared identifier

Happens here: libspeexdsp/testresample2.c Line 57

According to web sources, it is because 'M_PI' is not part of math.h or cmath in either C or C++, therefore i can imagine this out-of-the-box failure will appear for multiple environments.

Web sources suggest one of these solutions. I suggset speexdsp picks one for implementation.

Microsoft way (docs): "Math Constants are not defined in Standard C/C++. To use them, you must first define _USE_MATH_DEFINES and then include cmath or math.h BEFORE any other headers":

#define _USE_MATH_DEFINES
#include <cmath>
#incude other headers...

Different approaches, as you decide on portability and choice:

const double pi = 3.14159265358979323846;

#ifndef M_PI
    #define M_PI 3.14159265358979323846
#endif

GCC way:

#undef __STRICT_ANSI__
#include <cmath>

Compilers that support C++ 20 (use header numbers and constant pi), like so:

#include <numbers>
std::numbers::pi

cc @tmatth

The JitterBufferPacket::data field currently has type char *:

However, from the documentation it is not clear, whether the JitterBuffer will take ownership of the pointer or not. From the code I found here

I think in the second scenario, it would be good for the overall semantics, if JitterBufferPacket::data would become const char * to indicate that it will not be modified. However, that probably causes issues with the first scenario and also with backwards compatibility.

So in the end, I think it should just be documented more explicitly what happens with the passed pointer and who is responsible for freeing it.

Where can I find the API document?
help me please.... Thanks very much!!

jitter.c: In function ‘jitter_buffer_ctl’:
jitter.c:802:28: warning: ISO C forbids conversion of object pointer to function pointer type [-Wpedantic]
          jitter->destroy = (void (*) (void *))ptr;
                            ^
scal.c: In function ‘speex_decorrelate’:
scal.c:155:11: warning: unused variable ‘N’ [-Wunused-variable]
       int N=2*st->frame_size;
           ^

Feel free to build with -Wall -pedantic to help catch these.
Cheers.

can't download https://downloads.xiph.org/releases/speex/speexdsp-1.2.0.tar.gz

When it gets to this line: st = speex_preprocess_state_init(frame_size, 16000); I get the error message ld: symbol(s) not found for architecture x86_64. Any way for me to resolve this? Thanks!

See #40 to reproduce the problem.

I found an issue while passing 160 samples of 0 to function speex_preprocess_run. The first call to this function will raise "floating point divide by 0" exception. This exception does not raise if I pass correct voice data.

I have built the code with Visual Studio 2013 on Windows 7.

Thanks,
Akan

Adding a list of stuff SpeexDSP can do to the project's README would help people figure out whether they want to use it or not.
E.g.
"SpeexDSP includes:

• a resampler from and to 8, 12, 24, 41.1, 48... KHz
• a Voice Activity Detector (VAD)
• ...
  "

Hi,

I'm using SpeexDSP in a VoIP project to support Noise suppression. It works well on the Windows C++ application but failed with a "FLOAT_OVERFLOW" exception when I tried to use it in a Windows Delphi application.

After some debugging, I found the exception comes from the function qcurve:

When the input argument x is 0.000000, it MAY crash with the FLOAT_OVERFLOW exception(Sometimes, even if the x is zero, no error is reported).

I was able to make it work as expected like this:

static inline spx_word16_t qcurve(spx_word16_t x)
{
   //return 1.f/(1.f+.15f/(SNR_SCALING_1*x));
   return (SNR_SCALING_1*x) / ((SNR_SCALING_1*x)+0.15f);
}

Let me know what you think, and if you need more information.

Thanks.

devices :nexus 6p
speexdsp:1.2.0

Hi:
I would like to ask if I encountered a problem when I was about to perform real-time processing validation. I extracted 128 corresponding data from two. sw files and processed them for echo cancellation, resulting in very small values around 0, which is different from the results obtained using. sw files for processing.I don't know why this is happening.

Test code:

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include "speex/speex_echo.h"
#include "speex/speex_preprocess.h"
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdint.h>

#define NN 128
#define TAIL 1024

int test(short echo_buf[], short ref_buf[],short e_buf[])
{
SpeexEchoState *st;
SpeexPreprocessState *den;
int sampleRate = 8000;

st = speex_echo_state_init(NN, TAIL);
den = speex_preprocess_state_init(NN, sampleRate);
speex_echo_ctl(st, SPEEX_ECHO_SET_SAMPLING_RATE, &sampleRate);
speex_preprocess_ctl(den, SPEEX_PREPROCESS_SET_ECHO_STATE, st);

speex_echo_cancellation(st, echo_buf,ref_buf,e_buf);
speex_preprocess_run(den,  e_buf);

speex_echo_state_destroy(st);
speex_preprocess_state_destroy(den);

return 0;

}

int main(){
short a[128] = {76, -112, -42, -66, -86, 38, 30 ,92, 143 ,36, -85, -58, -34, -54, -61, -111, 51, 156, 51, -90, -223, -23 ,88, 11, 46, -2, 8, -99, -74, 192, 22, -105, 12,
-83, 127 ,274 ,-42, 33, 9, -38 ,6, -129, 169, -103, -142 ,302, -168, -4 ,137 ,-280, 73, 124, -29 ,168 ,105, -64, -21, 52, -121, -78 ,67, -50 ,43, 70,
-1, -14 ,-36, 188, -94, -366, 64 ,23 ,2, 189, -2, 26, 46, -100, -43 ,-23 ,-45, -15 ,-38, 85,179, 32, -110, -64 ,26, 0 ,55, -50, -93, 81, -93, -35, 99, -61, -35 ,-67, 22 ,41,
-61 ,76, 5, -152, -19, 129, -91, 28 ,232, -42, 8, -45, -183 ,-45, -17, 11 ,110 ,76 ,-86, 66, -17, -163, 249 ,135, -65, 128};

short b[128] = {-1092, -763, -479, -240, -38, 127 ,257, 359, 739, -10479, 2663, 2441, 2334, 1977 ,1763, 1562 ,14560, -1441, -1316, -1183, -1051, -929, -812,
                -705, 4991, 11916, -4122, -3613 ,-3132, -2689, -2283, -1909, -1061, -1372, -1096, -848, -630, -404, -291, -154 ,7945, 5695, -2728, -2328, -1453,
                -1728, -1418, -1138, -98 -793 -637 -453 ,13756, 10566 ,-5255 -4545 -3888 -3246 -2746 -2249 -1804 -1394 -1073 -772 -6 -395 -199,
                -34, 278 ,-12222 ,2738, 2522, 3095, 1962, 1720 ,1532 ,1530, -11245, 3466, 3042, 2674, 2259, 1916 ,1605, 14580, -1578, -1506, -1415 ,-1314, -1215,
                -1109, -1005, -903 ,-769 ,-717, -624 ,-543 ,-463 ,-393, -326, 6837, 11898, -4132, -3624, 10099 ,-5351, -4645, -3984 ,9873, -5467, -4668,
                -3930, 9980, -5300 ,-4466, -3701, -3015, -2402, -1861, -1385, 1066, -997, -694, -399, -150, 7269, -1226, -927};

short c[128];

printf("\n");
for (int i=0;i<2;i++){
    
}
test(a,b,c);

for(int i =0;i<128;i++){
    printf("%d",c[i]);
    printf(" ");
}

}

I ported all of the CPU intensive parts of the echo cancellation and preprocess to use the Apple's Accelerate framework. If it's of any interest, I can prepare and submit a PR.

Hello every one! I get an error at this step, it's:
./configure: line 10227: syntax error near unexpected token FFT,' ./configure: line 10227: PKG_CHECK_MODULES(FFT, fftw3f)'
Help me, please!

libspeexdsp/resample.c

2019-09-26T07:57:10.4651694Z analyze-build: INFO: /home/runner/work/dosbox-staging/dosbox-staging/src/libs/decoders/internal/speexdsp/libspeexdsp/resample.c:735:23: warning: Value stored to 'olen' during its initialization is never read
2019-09-26T07:57:10.4653274Z analyze-build: INFO:          spx_uint32_t olen = old_length;
2019-09-26T07:57:10.4654545Z analyze-build: INFO:                       ^~~~   ~~~~~~~~~~
2019-09-26T07:57:10.4655365Z analyze-build: INFO: 1 warning generated.

libspeexdsp/scal.c

2019-09-26T07:59:18.0313547Z analyze-build: INFO: /home/runner/work/dosbox-staging/dosbox-staging/src/libs/decoders/internal/speexdsp/libspeexdsp/scal.c:155:11: warning: Value stored to 'N' during its initialization is never read
2019-09-26T07:59:18.0314718Z analyze-build: INFO:       int N=2*st->frame_size;
2019-09-26T07:59:18.0315251Z analyze-build: INFO:           ^ ~~~~~~~~~~~~~~~~
2019-09-26T07:59:18.0315771Z analyze-build: INFO: 1 warning generated.

With the recent release of speex 1.2.0, are you planning to release speexdsp 1.2.0 any time soon?

When using dynamic resampling of a noisy sine (e.g. with 977 Hz) from e.g. 48000 Hz samplerate to 480001 samplerate, a frequency bounce of the resulting sine is visible which exceeds the actual frequency adaption.

Tested with

• SpeexDSP 1.2.0
• quality settings 3 and 10

This issue doesn't occur with a generated sine of the same frequency. This issue isn't visible with other resamplers as soxr or secret-rabbit-code (src) aka libsamplerate.

A sample code including WAV header handling is included. It can be used to generate a sine or use an input file (also attached). The resulting fundamental frequencies over time are attached for the original input and output signals. A similar plot can be achieved by using e.g. SonicVisualizer ('Layer' -> 'Add Peak Frequency Spectrogram' with max. Window size and a frequency zoom from 976 to 978 Hz).

Attachments:

• sample C++11 code
• input and resulting output files, frequency plots

Hi,
I have been working on the Speex adaptive jitter buffer. I am a little confused in understanding the specific get function:
int jitter_buffer_get(JitterBuffer *jitter, JitterBufferPacket *packet, spx_int32_t desired_span, spx_int32_t *start_offset);
*spx_int32_t start_offset parameter. I am attaching a snapshot. Could you please explain a little bit about this parameter?

Thank you!

I found that when resampling from 16k to 48k on the Raspberry Pi 3, libspeex sometimes introduces very bad distortion. I originally discovered this with ALSA's rate_speexrate plugin, but it occurs when libspeexdsp directly too. The installed version is libspeexdsp1-1.2~rc1.2-1 from Raspbian Jessie. The issue is not present on x86_64.

Here is the source code for a test case:
speex-resampler.tar.gz

sudo apt-get install sox libspeexdsp-dev
tar xf speex-resampler.tar.gz
cd speex-resampler
make
aplay test_48k.wav

This is what the waveform looks like before and after resampling:

resample_neon.h is inline assembly for armv7 32 bit NEON.
To compile this for aarch64, the functions need a port. The file contains 4 functions.
saturate_32bit_to_16bit()
inner_product_single(int16_t *a,...)
saturate_float_to_16bit()
inner_product_single(float *a,...)

resample.c includes the neon using a macro:

ifdef _USE_NEON

include "resample_neon.h"

endif

which needs to be set in the makefile.

Attached is a patch
resample_neon.txt

The typedef for JitterBufferPacket is

struct _JitterBufferPacket {
   char        *data;       /**< Data bytes contained in the packet */
   spx_uint32_t len;        /**< Length of the packet in bytes */
   spx_uint32_t timestamp;  /**< Timestamp for the packet */
   spx_uint32_t span;       /**< Time covered by the packet (same units as timestamp) */
   spx_uint16_t sequence;   /**< RTP Sequence number if available (0 otherwise) */
   spx_uint32_t user_data;  /**< Put whatever data you like here (it's ignored by the jitter buffer) */
};

If compiled in 64-bits that means that user_data is too narrow to hold a pointer cast to an int. It would be more useful to use uintptr_t:

struct _JitterBufferPacket {
   char        *data;       /**< Data bytes contained in the packet */
   spx_uint32_t len;        /**< Length of the packet in bytes */
   spx_uint32_t timestamp;  /**< Timestamp for the packet */
   spx_uint32_t span;       /**< Time covered by the packet (same units as timestamp) */
   spx_uint16_t sequence;   /**< RTP Sequence number if available (0 otherwise) */
   uintptr_t user_data;  /**< Put whatever data you like here (it's ignored by the jitter buffer) */
};

Hey there,

I was just taking a look trying to understand how the automated gain control works and did not understand how loudness_accum works in particular - it seems like it does not receive a value before being used here