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

[Jean-Marc Valin]

> OK, let's get things straight again:
> 
> - I prefer the built-in speex resampler in alsa-lib IFF...
>   o all related codes are released under LPGL explicitly

I'm willing to do that, but only if we already get the rest sorted out.

>   o there won't be too frequent updates that can't be handled as
>     patches

There's two issues:
- What's frequent?
- Can't be handled as patches depends mainly on how much you change the
code in your tree.

>   o we are allowed to modify codes as we like (mostly for clean ups)

The code is open-source, you do what you want with it. I'm only here to
make suggestions.

> - If one/many of these conditions isn't agreed, we can keep speex
>   resampler peacefully in alsa-plugins tree.  The default
>   configuration can be changed to use speexrate in the first
>   priority.  The rest would be a role of distro vendors.
>   Apparently you don't trust them but I do (at least it's one of my
>   jobs)...

OK, I have to admit I've got limited experience. Let's just say I don't
trust the Ubuntu maintainer :-)

> - If the update of resampler code may happen frequently, we can change
>   alsa-plugins/pph code to link with libspeex shlib to make the
>   maintenance easier.

About update frequency, keep in mind that you don't need to update every
time I change something. I'm expecting to make many changes, but that
would be more improvements than bug fixes.

> I sincerely hope that we agree with the first case (as my favorite
> choice), and appreciate any of your helps there.

I also hope we get that to work, but the only real power I have over
that is the first issue (license).

> Well, some random notes:
> 
> - RANDOM_PREFIX isn't sexy, and the inclusion of static functions may
>   give you more optimization

I considered static functions, but that means they can only be used from
one file and it means it's very easy to end up with multiple copies of
the code when compiling.

> - Any need of speex_*alloc?

Well, I need it in the main tree to make it easy for developers to
override the allocation function when porting Speex (e.g. on platforms
that don't have malloc). Basically, I want to make it possible to build
Speex without even linking to libc.

> - Ditto for home-baked ABS*() and MIN*() macros

Two things here. They need to be macros because they have different
definitions for float and int. Also, I need to be able to override then
with inline assembly, or debug versions.

> - Why not definitions in stdint.h?

Euh, how about because it's only part of C99? It may not matter to you
or ALSA, but it does for some users of Speex.

>> 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 know exactly, but there have been requests, and we have to
> deal with it.

Well, it's in the plans, but it won't happen overnight.

>> 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.
> 
> Oh no, I don't blame that I found any security issues.  Otherwise I
> would have fixed it.
> 
> What I meant is that any serious problems could be much easily fixed
> in one place if we use a shlib approach.  Of course, the drawback is
> the breakage can happen easily as well.  But, still the plugin can be
> disabled at any time as long as we have a fallback.

Actually, how about having the copied code as fallback in case the shlib
isn't there?