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 issues).
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.
OK.
thanks,
Takashi