[alsa-devel] [Alsa-devel] Quality resampling code for libasound

[Jean-Marc Valin]

> 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