similar to: Speech Detection

Hello, some misc. cleanup patches for speexdsp, nothing big I'm not sure about how to submit patches, so this is a test balloon :) ultimately, I'd like to fix the FIXED_POINT issue, see http://lists.xiph.org/pipermail/speex-dev/2013-December/008465.html currently, I think the only way to find out how speexdsp has been compiled is to resample some bytes and observe the output; which is

Hi everyone, Just to let you know that version 1.2beta3 is out. The main change is the split into libspeex and libspeexdsp. Basically, libspeex keeps the codec (just like it was for 1.0.x) and libspeexdsp has all the new components. Other changes include a new jitter buffer algorithm and resampler improvements/fixes. This is also the first release where libspeex can be built without any floating

Hi, I have problems compiling speex 1.2rc1: > /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I. - > I.. -I../include -I../include -I.. -I/opt/csw/include -I/opt/csw/ > include -xO3 -xarch=v8 -I/opt/csw/include -c skeleton.c > /bin/bash ../libtool --mode=link /opt/studio/SOS11/SUNWspro/bin/cc - > xO3 -xarch=v8 -I/opt/csw/include -xarch=v8 -L/opt/csw/lib -o

Hi all, I am a newbie here and just started using speex in our lab. During compiling my voice application with windows-compiled version provided today, I am getting "unresolved external symbol _speex_wb_mode". I am probably missing some setting with VS6.0 linker... (I am a bit new to windows too) If anyone could point it out, I would appreciate it. - Tim -----Original Message-----

Hi Aymeric, > 2 questions: I count 4 :-) > * Do you "feel" that the current svn is enough stable Yes. I'm planning on releasing it as 1.2beta3 this week. Even in normal time, I try to keep svn in good shape so it is almost always better than the last release. And even when it breaks, Speex bugs tend to be very obvious and easy to reproduce (no segfaults that happen once a

I'm currently working on packaging the latest version of speex for Fink, a Mac OS X package manager. Our current speex version is at 1.1.6, and several new programs require a newer version, which is why I'm working on the update. When 1.2b3 was released and some symbols were offloaded to libspeexdsp.1.dylib, this broke the library on OS X since libspeex.1.dylib kept the same install

Hi Jean-Marc, Am 17.04.2009 um 13:35 schrieb Jean-Marc Valin: > It should be using getopt1.c when getopt isn't available.c. Can you > check why it doesn't? In any case, that's only required for the Ogg > tools, not for the library. config.log says ac_cv_func_getopt_long=no ac_cv_header_getopt_h=no ac_cv_lib_gnugetopt_getopt_long=no LIBOBJS='

Hi, Attached is a patch which enables FFTW3 to be used by libspeexdsp. Using SSE, the FFT code is more than twice as fast, and it's 50% faster even without SSE. To enable the library, you'll need to call configure with '--with-gpl-fftw3'. Based on the benchmarking we did, this also changes the default FFT to smallft for floating point implementations when not using FFTW3.

Guys, I''ve successfully ran dom0/domU (both Debian) in my local laptop using 2.6.32.15 dom0 with xen-4.0.1-rc3-pre. Great. Now I want to install it into couple of test-machines without compiling from source. So I did following.. a. make dist-xen b. make dist-tools PYTHON_PREFIX_ARG="--install-layout=deb" c. make dist-stubdom This

Hi all, I'm updating OpenEmbedded-core's speexdsp from 1.2rc1 (when it still was a part of the speex source tree) to 1.2rc3. I found out that building the new version for aarch64 fails in resample_neon.h (the target machine is OE-core's default qemuarm64 target). This is the error message: .../speexdsp-1.2rc3/libspeexdsp/resample_neon.h:148:5: error: impossible constraint in

Hi all, I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I build with i386, X86_64, armv7 and armv7s all passed. But when I build for ARM64 (for iPhone 6), it failed with: /Applications/Xcode.app/Contents/Developer/usr/bin/make all-recursive Making all in libspeexdsp CC preprocess.lo CC jitter.lo CC mdf.lo CC fftwrap.lo CC

Hi All, We are using speex for linphone in blackfin fixed point platform. The speex version we are using is svn-14525. If we don't disable vbr by "--disable-vbr", the sound quality will be very bad in linphone. But if we disable it, sound will be perfect. I noticed in the speex.org, there is a comment like this: > >Speex 1.2beta3 is out >December 11, 2007 >The most

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, On Sat, Mar 28, 2015 at 2:34 PM, Evan JIANG <firstfan at gmail.com> wrote: > Hi all, > > (Sorry that may be duplicated that I was not a mail-list member before, > so last mail sent failed) > > I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I > build with i386, X86_64, armv7 and armv7s all passed. > But when I build for ARM64 (for

On Tue, 2015-07-07 at 18:40 +0930, Ron wrote: > On Mon, Jul 06, 2015 at 05:35:51PM +0300, Tanu Kaskinen wrote: > > Hi all, > > > > I'm updating OpenEmbedded-core's speexdsp from 1.2rc1 (when it still was > > a part of the speex source tree) to 1.2rc3. I found out that building > > the new version for aarch64 fails in resample_neon.h (the target machine

From: Tanu Kaskinen <tanu.kaskinen at linux.intel.com> 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

Jean-Marc, Frank, I have stumbled across a similar situation regarding optimization. I seem to have a similar setup as Frank does with a fixed 48khz in and out. The wideband mode and ultra-wideband modes are really what I?m looking for. I have a test application that reads audio, downsample to 16kHz (or 32kHz), speex encode, speex decode, upsample back to 48kHz, and playback. If I remove

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])

Signed-off-by: Peter Meerwald <pmeerw at pmeerw.net> --- libspeexdsp/resample.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/libspeexdsp/resample.c b/libspeexdsp/resample.c index e32ca45..a19b997 100644 --- a/libspeexdsp/resample.c +++ b/libspeexdsp/resample.c @@ -85,7 +85,7 @@ static void speex_free (void *ptr) {free(ptr);} #ifdef FIXED_POINT #define

I actually forgot to mention that I'm using ultra-wideband mode, but seems like you understood that anyway. Is this true that Speex echo cancellation only performs well in narrowband mode !? I've been using 100 ms as the default tail length. I don't know what the ideal tail length would be. I have tried shorter and longer tails but it hasn't made any difference. Does