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@xiph.org wrote:
Send Speex-dev mailing list submissions to
speex-dev@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@xiph.org
You can reach the person managing the list at
speex-dev-owner@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@natvig.com>
Subject: Re: [Speex-dev] Library split (poll)
To: speex <speex-dev@xiph.org>
Message-ID: <Pine.LNX.4.62.0606291652150.30841@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@xiph.org
http://lists.xiph.org/mailman/listinfo/speex-dev
End of Speex-dev Digest, Vol 25, Issue 24
*****************************************
