> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
