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

Takashi Iwai tiwai at suse.de
Thu Mar 22 00:35:08 CET 2007


At Thu, 22 Mar 2007 09:08:32 +1100,
Jean-Marc Valin wrote:
> 
> >>> 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.

Well, this comes from the difference of thoughs regarding the
distribution.  See below.

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

Fine, then this is no problem at all, then.

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

This is different understanding between us.

I'm working at a distro vendor, and as a responsible person for
distribution packages, the first thought is maintainability.
For that purpase, I prefer very much a shared library approach because
I know the hell of vice of copying codes.  Copying code works well if
it's 100% safe and mature code, which requires no longer updates and
fixes.  But a code being developed shouldn't be copied.

That is, the only criteria for inclusion is whether the code is well
tested and no more fix/update is needed.  In this case, whether
resample code has to be further sync'ed with speex codebase or not.
If it should be kept synced, then shlib approach is clearly better.
Otherwise we have to take care of two places at the same time.

Or, in other words:  the sound quality could be a matter of taste, but
a security fix can't be so :)


Takashi


More information about the Alsa-devel mailing list