[alsa-devel] [Alsa-devel] Quality resampling code for libasound
Takashi Iwai
tiwai at suse.de
Wed Mar 21 16:43:52 CET 2007
At Thu, 22 Mar 2007 02:17:56 +1100,
Jean-Marc Valin wrote:
>
> > 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.
OK.
> > 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.
Well, this arises another question:
If the code is not allowed to modify, why to bother to include the
code in the tree? Why not use a shared library?
> > 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.
I personally don't like the dual license. It can't work seriously if
someone changes/forks the code.
> > 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.
I feel the easiest way for both of us is just to keep alsa-plugins as
it is. (Or, even better, we can modify alsa-plugin configure script
to detect libspeex, too. This will decrease the maintenance const.)
Then, change alsa-lib rate plugin to look up the list of plugins, and
put "speexrate" to the top of it and "linear" to the bottom in the
default configuration, so that speex resampler can be used (if
installed) and the built-in linear plugin can be safely used as a
fallback.
Takashi
More information about the Alsa-devel
mailing list