similar to: compiling with --enable-valgrind

Description =========== This patch adds support of CMake meta build system, so you can generate Unix makefiles, VS 6.0-2017 projects and many more. Features ======== * Win32 and Linux tested * Travis CI test added * Generates working Visual Studio 6.0-2017 solutions * Generates working Unix Makefile * Supported options (<option> - <default value>): * `ENABLE_FLOATING_POINT` - on

When built with --with-fft=gpl-fftw3, libspeexdsp is not linked with libfftw3, while it uses symbols from it. This means every object linked with libspeexdsp should also be linked with libfftw3, but it is not something reflected in the pkgconfig file. Instead, link libspeexdsp with libfftw3 when --with-fft=gpl-fftw3, and remove explicit link with libfftw3 in objects build by the speex Makefile.

Hi there. I am having a little trouble understanding the frame sizes chosen by the codec. testenc_uwb.c from the speex-1.0 source distribution has a framesize of 640 hardcoded and makes use of this value exclusively. However, a mode query on the actual codec returns 320 as a framesize for this mode. int tmp; speex_mode_query(&speex_uwb_mode, SPEEX_MODE_FRAME_SIZE, &tmp);

Oops... You've just found a bug. Seems like you're the first one to use that call. Anyway, it's now fixed in CVS (both trunk and 1.0.x branch). Thanks for the bug report. Jean-Marc Le mar 03/06/2003 à 01:16, Christian Buchner a écrit : > Hi there. > > I am having a little trouble understanding the frame sizes chosen > by the codec. > > testenc_uwb.c from

Hi, Everyone! I'm developing VoIP application using Speex, have some questions: 1) When ultra-wideband mode should I use 32000 Hz sampling rate only? If I use 44100 Hz the voice quality seems to be better comparing to 32 KHz. 2) When I use wideband mode with 16 KHz sampling rate bandwidth usage is greater comparing to 32 KHz, ultra-wideband. Why? Voice quality is worse when using 16KHz

Since two people have asked me to open the source code on my work-in-progress Integer Speex project, I have put it up onto my site www.openacm.org as a download in the project tree. the suggested directory structure is as follows, i.e. the speex source folder should be on the same directory level as the sphinx filder. peex-1.0.1 (ideally the folder from within the SpeexACM source archive)

DEAR: I SEEM A BUG FOR speex-1.2rc1.tar.gz ON BUILD IN USING IT. PLEASE LOOK: ===================================================================== make all-recursive make[1]: Entering directory `/tmp/speex-1.2rc1' Making all in libspeex make[2]: Entering directory `/tmp/speex-1.2rc1/libspeex' /bin/sh ../libtool --mode=link gcc -g -O2 -fvisibility=hidden -O3 -msse -o testenc

I suspect I am missing something basic but I do not seem to be able to get the sampleenc and sampledec programs to work together. I think I do not have a compile swtich of flag set correctly. Backgound information: 1) 1.0.4 tar package 'make' worked and installed on a mandrake 10.0 linux 2) speexenc and speexdec appear to work fine. 3) testenc and testenc_wb work fine, though I

I suspect I am missing something basic but I do not seem to be able to get the sampleenc and sampledec programs to work together. I suspect the decode operation is failing, but I cannot find out why. Backgound information: 1) 1.0.4 tar package 'make' worked and installed on a mandrake 10.0 linux 2) speexenc and speexdec appear to work fine. 3) testenc and testenc_wb work fine, though

NUT developers, just thought I'd share some notes and ideas on using valgrind against the NUT USB drivers on Linux. Stepping back a bit, I wanted to make sure that the tripplite_usb driver* wasn't using any uninitialized memory, or leaking memory over time. valgrind (specifically, the memcheck tool) runs the code in a special dynamic translator that checks every memory access to see if

Hi all, I'm new to the group. I'm looking at the speex code with an eye towards maybe helping out with either codec optimization or fixed-point implementation, The SNR calculation in testenc.c and testenc_uwb.c doesn't make sense to me. The code is { float enoise=0, esig=0, snr; for (i=0;i<FRAME_SIZE;i++) {

Hi, all. I have two questions about wideband encoding. >From "testenc_wb.c"... 1) tmp=8; speex_encoder_ctl(st, SPEEX_SET_QUALITY, &tmp); tmp=3; speex_encoder_ctl(st, SPEEX_SET_HIGH_MODE, &tmp); tmp=6; speex_encoder_ctl(st, SPEEX_SET_LOW_MODE, &tmp); How to set high_mode and low_mode, if quality is set to '9'? When I set quality '9'

Actually, the SNR calculation in testenc has been broken for a while. The reason for taking the last frame was that the codec would introduce a one-frame latency. I changed that to half a frame (10 ms) a while ago and never updated testenc. Jean-Marc Le lun 01/09/2003 à 13:12, Mike Dunn a écrit : > Hi all, > > I'm new to the group. I'm looking at the speex code with an

Hi, speex developers! I'm new to speex, and trying to build a simple echo application. something like this. microphone -> speex encoder -> speex decoder -> speaker I first test it the simple way, microphone -> do nothing -> speaker and this works fine. But when I try to encode speex, and decode it, it works, but some high frequency noise is added. How can I fix it? The

Hi, speex developers! I'm new to speex, and trying to build a simple echo application. something like this. microphone -> speex encoder -> speex decoder -> speaker I first test it the simple way, microphone -> do nothing -> speaker and this works fine. But when I try to encode speex, and decode it, it works, but some high frequency noise is added. How can I fix it? The

The resampler will convert raw audio from one sample rate to another. You are starting with Speex-encoded audio frames. So, what you need to do is: 1. Run the media frames through the Speex decoder (look at Speexdec or testenc_uwb). This will give you raw audio with a 32 KHz sample rate. 2. Use the resampler to convert the audio from 32 KHz to 8 KHz sample rate. 3. Run the 8KHz audio

This patch enables compilation with GCC 4.7.1 and --enable-shared=yes --enable-static=no --enable-vorbis-psy -------------- next part -------------- diff -r -u speex/configure.ac speex/configure.ac --- speex/configure.ac 2013-04-24 19:08:00.710564608 +0400 +++ speex/configure.ac 2013-04-24 20:04:33.589310544 +0400 @@ -204,7 +204,7 @@ AC_DEFINE([TI_C55X], , [Enable support for TI C55X DSP])

No, although its declared in the Path.h file, its actually not in the Path class. Have a look. Not sure why you're still seeing that problem. The same change to Unix/Path.cpp fixed the same problem on Cygwin and Linux. Reid. On Thu, 2004-12-23 at 15:48, Henrik Bach wrote: > Hi Reid, > > The error still exists. However, looking on the function in Win32/Path.cpp: > --------------

But breaks VC++. The problem is, Windows.h defines "CopyFile" as a macro that's either "CopyFileA" or "CopyFileW". Path.h is included before Windows.h, so the declaration has the name "CopyFile" while the definition has "CopyFileA". Instant compilation error. Not sure what the best way to fix it is, but I'll check it in as soon as I

Hi Reid, The error still exists. However, looking on the function in Win32/Path.cpp: -------------- void sys::CopyFile(const sys::Path &Dest, const sys::Path &Src) { if (!::CopyFile(Src.c_str(), Dest.c_str(), false)) ThrowError("Can't copy '" + Src.toString() + "' to '" + Dest.toString() + "'"); } -------------- I