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

[Takashi Iwai]

At Thu, 22 Mar 2007 00:39:44 +1100,
Jean-Marc Valin wrote:
> 
> > Yeah, this is an interesting question.  We often see similar conflicts
> > in the maintenance of linux kernel tree, too.  The unified coding
> > style gives clearly better readability of the whole tree.  OTOH, if a
> > code chunk is derived from another tree, it requires more additional
> > backport effort.
> 
> I think the main question is: do you plan on making many alsa-specific
> changes to that code?

Yes (not alsa-specific but less speex-specific), 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...)

> resampler.c is pretty much as close as you get to
> pure signal processing code (no "system" stuff), so I don't think many
> people will actually want to mess with it and any improvements might as
> well be merged in Speex first to be tested for a while. Of course, if
> the coding rules are simple, an other approach could be to automatically
> re-indent the code when syncing. Of course, it still means you need to
> keep the same code as Speex has. In any case, I'd recommend not forking
> that code too early because some of the planned improvements (e.g. SSE
> optimisations) could be a pain to backport.

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.

> > In the ideal situation, we may link to speex resampler as a dynamic
> > library -- e.g. adding a configure option to let user choose the
> > built-in or system-wide library resampler code.  Does libspeex provide
> > this code snip as exported?
> 
> Not sure I understand what you mean here. If you're asking whether the
> symbols for the resampler are exported in the shared library, then the
> answer is yes -- though the resampler is only in the svn version of
> Speex for now. The first release to include it will be 1.2beta2, which
> I'm planning to release in a few weeks.

Ah, OK.  I asked it because I couldn't find symbols in my libspeex
binary.


Takashi