[Speex-dev] Re: Library Split Poll

[Sol Young]

I vote for splitting 'em off and documenting the great features of  
each.  I've been using the codec for a while now and would be more  
likely to dig in to the additional features if they were offered as  
separate components so I could use them with other audio projects (as  
well as being more likely to use those features in speex, simply  
because they would be easier to dig in to at that point).

Sol

On Jun 29, 2006, at 3:00 PM, speex-dev-request at xiph.org wrote:

Send Speex-dev mailing list submissions to
	speex-dev at xiph.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.xiph.org/mailman/listinfo/speex-dev
or, via email, send a message with subject or body 'help' to
	speex-dev-request at xiph.org

You can reach the person managing the list at		
	speex-dev-owner at xiph.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Speex-dev digest..."


Today's Topics:

    1. Re: Library split (poll) (Thorvald Natvig)


----------------------------------------------------------------------

Message: 1
Date: Thu, 29 Jun 2006 16:58:06 +0200 (CEST)
From: Thorvald Natvig <speex at natvig.com>
Subject: Re: [Speex-dev] Library split (poll)
To: speex <speex-dev at xiph.org>
Message-ID: <Pine.LNX.4.62.0606291652150.30841 at mix.hive.no>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

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



------------------------------

_______________________________________________
Speex-dev mailing list
Speex-dev at xiph.org
http://lists.xiph.org/mailman/listinfo/speex-dev


End of Speex-dev Digest, Vol 25, Issue 24
*****************************************