[alsa-devel] [Alsa-devel] Quality resampling code for libasound
jean-marc.valin at usherbrooke.ca
Fri Mar 23 22:33:18 CET 2007
> 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
> 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
More information about the Alsa-devel