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