Well, maybe that's the whole point -- how to manage the included code. If it's linked to libspeex, yes, the plugin would rely on libspeex in 100%. This allows the automatic addition of new features like SIMD support. But, this is a drawback, too, if the library gets broken although in this case, the possible problem could be easily removed by removing the offending plugin. (The alsa-lib itself won't be linked to libspeex, anyway. Only the plugin will.)
I thought the idea was to move the resampler from alsa-plugin to alsa-lib?
Oh, I'm in very favor of using a better resampler as default, too.
So are you willing to make the resampler (in one form or another) a mandatory dependency?
Regarding code-rewriting, I think you misunderstood my early comment. It's not the urgent issue to rewrite the code indeed. But, it may (likely) happen to get rid of the speex-specific redundant codes
I still haven't seen any example of redundant code outside of the few lines where I define the spx_int* types.
afterwards or change the indentation and coding styles in near future in a long run afterwards. This is how the code is being maintained just like in the linux kernel tree.
I thought the Linux kernel was simply copying the alsa tree once in a while. Are they really doing independent modifications?
So, as long as we'll be able to play with the code in alsa-lib tree as we like, and you agree with LGPL, the code inclusion can happen easily. Of course, for reducing the future maintenance cost, we should double-check the code before inclusion. But, in the case of resampler, the code flow is easy, so it wouldn't be a big obstacle :)
BTW, one remaining concern is architectures that don't like math library. Could sin() and floating point operations be removed from resampler code? Otherwise, I can make the built of pph resampler conditonal to softfloat configure option.
It is my plan to get rid of any float operation in there, but it will likely take a little while. sin(x)/x can be easily replaced by a lookup table, but the remaining float operations might take a while to remove. How many architectures don't have soft float anyway?
I don't see much security issues here. The code is really simple and (unless I've done something really obviously stupid -- which I don't think I have) you can easily show that there's no buffer overflow possible.
Well, you should check the return value of speex_*alloc() at least ;)
Sure I was going to fix that (still need to return error values), but there's no security issue there, as it will just crash in case of OOM condition.
Jean-Marc