Re: [Alsa-devel] Quality resampling code for libasound

[Jean-Marc Valin <jean-marc.valin@usherbrooke.ca>]

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

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

	Jean-Marc