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

Takashi Iwai tiwai at suse.de
Wed Mar 21 15:53:12 CET 2007

At Thu, 22 Mar 2007 01:19:18 +1100,
Jean-Marc Valin wrote:
> > Yes (not alsa-specific but less speex-specific), 
> Outside of the spx_int* types, what are the speex-specific bits that
> bother you?

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.

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.

> > once if it's merged
> > to alsa-lib tree.  (The code can't be applied to the tree as it is,
> > BTW, because it must be LGPL, as we discussed...)
> Is a COPYING file OK or do you need headers (in which case, what's the
> smallest header that can be added?)?

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

> > Yes, but if the code is in another tree, it's actually a fork.
> > Having codes that may be frequently changed in multiple places is
> > already a risky action from the maintenance POV, regardless of the
> > coding style.  That's what I'd like to avoid.
> Then the solution would be to just copy from the Speex tree once in a
> while and get the fixes there first. You can always have an automated
> formatting tool that you run after importing a new version. Overall, I
> really see no reason why you'd want to modify the resampler in the first
> place -- other than fixing bugs, which should go in the Speex tree anyway.

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

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


More information about the Alsa-devel mailing list