[alsa-devel] [Alsa-devel] Quality resampling code for libasound

Jean-Marc Valin jean-marc.valin at usherbrooke.ca
Wed Mar 21 16:17:56 CET 2007

> There are lots of macros in arch.h and speex_resampler.h, which try to
> absorb the difference from non-C99 and non-LP32 platforms.

Actually, most of the stuff in arch.h is designed to abstract the
operators so they can be defined for fixed-point or floating point (e.g.
spx_word32_t is defined either as float or as int depending on how you
compile). There's nothing about non-C99 stuff and the only non-LP32
stuff are the few spx_int* types.

> BTW, I'm not against these codes at all in general.  But, between
> speex and alsa-lib, the target is simply different.  Hence the code
> should be written in a different manner accordingly.

But is it worth increasing the maintenance overhead for code that may
never be modified directly in alsa. Note that I'm not talking about the
plugin code that uses the resampler here.

> Each file in pph/* contains the BSD headers, so we have to change them
> anyway.

Can't we just add a "Oh and BTW, you can also use it under the LGPL"
right after the BSD header. This is something I'd be willing to do in
the Speex tree. Apply a new license when syncing code seems like a bad
idea to me.

> IMO, it never worked well, looking at history.  For example, you can
> find a piece of zlib code everywhere, but they are not synchronized
> and well bugfixed (especially thinking of many security fixes in
> zlib).

Well, I can't really think of something better for now.

> The only working solution for synchronized source management is to use
> the shared library.

You could do that too, but it means you'll be forcing libspeex >
1.2beta2 onto all distributions. I don't mind because it should be quite
a good release, but maybe some will object. I'd suggest just doing a
copy in the short term and then move to the shared library when distros
have it.


More information about the Alsa-devel mailing list