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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
