Hi everyone, In the 1.1.x branch, I've kept adding more stuff to libspeex: preprocessor, AEC, etc. I'm now considering moving all those to a separate library (libvoip, libspeech, whatever). Anyone on this list has good reasons I should consider for either splitting or not splitting libspeex? Cheers, Jean-Marc
Hi Jean-Marc, I think it is a good idea to split everything off that is not integral part of the codec and could be used with other codecs e.g. voice activity detection, echo cancellation, jitter buffer etc. I have already used the echo cancellation without a codec. Ruotger Am 27.06.2006 um 15:04 schrieb Jean-Marc Valin:> Hi everyone, > > In the 1.1.x branch, I've kept adding more stuff to libspeex: > preprocessor, AEC, etc. I'm now considering moving all those to a > separate library (libvoip, libspeech, whatever). Anyone on this > list has > good reasons I should consider for either splitting or not splitting > libspeex? > > Cheers, > > Jean-Marc > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev--- Endian Little Hate Programmers Ruotger Skupin, Mac OS X Software Engineering ilink Kommunikationssysteme GmbH M?nzstr. 13; 10178 Berlin - Germany
Jean-Marc Valin wrote:> In the 1.1.x branch, I've kept adding more stuff to libspeex: > preprocessor, AEC, etc. I'm now considering moving all those to a > separate library (libvoip, libspeech, whatever). Anyone on this list has > good reasons I should consider for either splitting or not splitting > libspeex?I'd argue for a separate library; in space-constrained environments, it would be good to be able to easily not include these additional features. Gerv
Jean-Marc Valin wrote:> In the 1.1.x branch, I've kept adding more stuff to libspeex: > preprocessor, AEC, etc. I'm now considering moving all those to a > separate library (libvoip, libspeech, whatever). Anyone on this list has > good reasons I should consider for either splitting or not splitting > libspeex?Ordinarily, I'd say we already have enough tiny little dependent libraries, but if this is growing into a set of voip-ish tools that are generally applicable outside speex (ghost for example?) then it's a reasonable idea. I think the important question is whether it's likely to keep growing and generalizing (yes) and how coupled it is to the speex codec (no). FWIW, -r
I have sent the visual studio project files that compile the speex client to jean-marc directly (as an attachment), sometime this week, I will also upload the binary builds of static library files to my site www.phonestack.com. I am porting our LTP (lightweight telephony protocol) to some embedded systems. I require to run speex in an environment that doesn't support memory allocations. How difficult is it to convert speex_encoder_init and speex_decoder_init to use preallocated memory buffers (presumably passed by the initilisatio functions themselves)? - farhan - farhan -----Original Message----- From: speex-dev-bounces@xiph.org [mailto:speex-dev-bounces@xiph.org] On Behalf Of Gervase Markham Sent: Wednesday, June 28, 2006 2:55 AM To: Jean-Marc Valin Cc: speex Subject: Re: [Speex-dev] Library split (poll) Jean-Marc Valin wrote:> In the 1.1.x branch, I've kept adding more stuff to libspeex: > preprocessor, AEC, etc. I'm now considering moving all those to a > separate library (libvoip, libspeech, whatever). Anyone on this list > has good reasons I should consider for either splitting or not > splitting libspeex?I'd argue for a separate library; in space-constrained environments, it would be good to be able to easily not include these additional features. Gerv _______________________________________________ Speex-dev mailing list Speex-dev@xiph.org http://lists.xiph.org/mailman/listinfo/speex-dev
Jean-Marc Valin wrote:> Hi everyone, > > In the 1.1.x branch, I've kept adding more stuff to libspeex: > preprocessor, AEC, etc. I'm now considering moving all those to a > separate library (libvoip, libspeech, whatever). Anyone on this list has > good reasons I should consider for either splitting or not splitting > libspeex? >good idea to split the libraries If e.g. AEC/Jitterbuffer can be used with other codecs such as G711, without linking to the speexcodec lib, I think people will reuse the Speex jitterbuffer implentation and avoid writing their own. what about: libspeexpreproc Preprocessor libspeexaec Acoustic Echo Cancellation libspeexjitter Jitter buffer libspeexcodec Speex codec itself it would also make sense if the makefile/configure script of the applications using the Speex libraries can automatically detect which libraries/header files are installed on the system. /alfred
Hi Jean Marc, On Wed, 28 Jun 2006, Alfred E. Heggestad wrote:> good idea to split the libraries > > If e.g. AEC/Jitterbuffer can be used with other codecs such as G711, > without linking to the speexcodec lib, I think people will reuse the > Speex jitterbuffer implentation and avoid writing their own. > > what about: > > libspeexpreproc Preprocessor > libspeexaec Acoustic Echo Cancellation > libspeexjitter Jitter buffer > libspeexcodec Speex codec itselfIn case you split, I really like this naming which still show that those projects are part of speex. The more features you have "inside", the best "speex" is -> even if the feature is not directly related to the codec. Thus, I also advise you to also keep the splitted libraries in the SAME archive. It's not because you split the build that you should split the archive and source!> it would also make sense if the makefile/configure script of the > applications using the Speex libraries can automatically detect > which libraries/header files are installed on the system.In case of one archive, the process for speex maintainer and developper will be much easier. Tks, Aymeric> /alfred > > _______________________________________________ > Speex-dev mailing list > Speex-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/speex-dev > >
> Hi everyone, > > In the 1.1.x branch, I've kept adding more stuff to libspeex: > preprocessor, AEC, etc. I'm now considering moving all those to a > separate library (libvoip, libspeech, whatever). Anyone on this list has > good reasons I should consider for either splitting or not splitting > libspeex?I'd much prefer it if it was still just one library. At the moment, I bundle the library with my Win32 applications (and one file is better than 3), and for Linux compiles, it's much much easier to check the version of speex and then do a few appropriate #ifdef around the code, than having to check the version of each of the libraries (at compile time) and have different code for each possible combination of library versions that you wish to support. For space-constrained projects, you can use a static library and a linker which only pulls out the object files actually needed (or alternately compile a version of the library for that specific purpose). Actually, I'd kinda like to see even tighter integration between the different parts. At the moment, there's FFT back and forth at the end of echo / preprocess / start of encode.. Couldn't we just use the frequency-domain data from the preprocessor directly in the encoder?