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

Takashi Iwai tiwai at suse.de
Mon Mar 26 14:40:52 CEST 2007

At Mon, 26 Mar 2007 21:47:49 +1000,
Jean-Marc Valin wrote:
> > 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?

I'd say once per week.

> - Can't be handled as patches depends mainly on how much you change the
> code in your tree.

Right.  As mentioned earlier, I have also no plan to rewrite the codes
so urgently.  Let's settle down it first.
> >   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.

OK, good to hear.

> > - 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 :-)

Heh, you can simply bug them :)

> > - 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.

OK.  Then it's no big problem from my side.

> > 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).

Yeah, the license is a nasty issue, but it's crucial for open-source
at the same time.

> > 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.

 From the POV of library, I of course agree with such workarounds.
The suggestions above are the possible clean-ups that could be
applied once after included in alsa-lib tree (again, non-urgent

> >> 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.

OK, for such architectures, we can disable the plugin.  They are
anyway rare, so you won't be bothered.

> >> 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?

Yes, that's my idea, too.  That is, _adding_ the configure option to
make use of libspeex.

> >From other email:
> > Agreed.  I just thought that fixed-point is used as default in your
> > resampler code but it seems wrong.
> No, floating-point is used unless you define FIXED_POINT. As I was
> saying, on any recent PC, the float version (even without SSE) is faster
> and has better quality than the fixed-point version.




More information about the Alsa-devel mailing list