similar to: please promote libspeex1 (speex-1.2rc1) to libspeex on Sarge before end of month

This is resolved: apt-get remove libspeex-dev cd ~/src/speex-1.2rc1/ ./configure --prefix=/usr make; make install cd ../ffmpeg ./configure --enable-libspeex make; make install worked; then I was able to decode a Speex .flv file: ~/flvs$ ffmpeg -i SpeexQ6R16Efalse.flv foo.wav FFmpeg version SVN-r17174, Copyright (c) 2000-2009 Fabrice Bellard, et al. configuration: --enable-libspeex

I am having trouble compiling ffmpeg to support speex, which didn't work with the ubuntu libspeex-dev package, but looks like it might with the Speex version 1.2rc1 tarball from http://speex.org/downloads/ How do I tell ffmpeg's configure and/or make to use the 1.2rc1 version of libspeex in /usr/local/include instead of the older debian/ubuntu libspeex-dev package in /usr/include/speex?

Mikael Magnusson writes: > Package: libspeex1 > Version: 1.1.6-1 > Severity: wishlist > > Is there anything that keeps 1.1.6-1 in experimental from being uploaded to > unstable? Do you know when it will happen? > > I'm debianizing iaxclient, which needs speex version 1.1.x. Currently I'm > using 1.1.6-1 in experimental, which is working fine. >

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, 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

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. Jean-Marc Dagobert Michelsen a ?crit : > Hi, > > I have problems compiling speex 1.2rc1: > >> /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I. - >> I.. -I../include

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

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.

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

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

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

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

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

On Tue, Apr 15, 2014 at 12:33 PM, Peter Meerwald <pmeerw at pmeerw.net> wrote: > 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 > ---

Ok, let me be more clear on this. AFAIK, Windows OS doesn't expose speaker input as other OS ( Linux, Mac OS...). That puts you in bad spot in using Speex AEC with windows. Only way to work is to use Soundcard with ASIO functionality which does give you speaker input. But then you would have to impose that requirement on all your users. I heard Speex AEC works great from developer who

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 > is OE-core's default qemuarm64 target). This is the error message:

Hello! I couldn't find any recent discussion of this, so thought I'd post, and I'm not clear who maintains the Win32 build environment or I'd have contacted them directly. I've finally gotten around to turning voice back on in my project, and I'm having issues with obtaining a stable build in VS2005. I've checked out SVN trunk of obb (as libogg) and speex, built

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

Well, I am not the person to be asked about how Speex AEC works :) And I was referring speaker input as having direct access into what has been played thru speaker. (ASIO Soundcard provides interface for that) So if I am remebering correctly, with data from Mic and Speaker in sync, speex AEC should do the job. Tim _____ From: Guilherme Balena Versiani [mailto:guibv at