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

[Jean-Marc Valin]

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

Well, first it's nod forbidden to modify it, just saying there probably
isn't much point in doing so. I think using a shared library actually
makes sense in the long term, but in the short term it may cause
problems for distributions. Another concern is making an optional
libspeex dependency and having all the distros skip that and end up with
the good 'ol shitty resampler again. As I've mentioned before, my #1
goal here is to make sure nobody ever ends up with that resampler again
unless actively attempting to.

> I personally don't like the dual license.  It can't work seriously if
> someone changes/forks the code.

Nothing to do with dual-license. I can fork ALSA and make it GPL easily.
Making the resampler dual-licensed right in libspeex would actually make
it very easy for everyone.

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

But then we've got the same problem as above. Users will not manually
install alsa-plugin and I doubt we can trust distros to do the right
thing. Really, I don't understand why the whole thing needs to be made
that complicated. At this point, I think plain forking the code (and
changing all the style and everything) with no interactions with the
Speex trunk is still preferable to the options above. At least it means
a decent resampler is actually being used -- 100% of the time.

	Jean-Marc