Package Name: djbfft Version: 0.76 Upstream Author: D. J. Bernstein URL: http://cr.yp.to/djbfft.html License: Public Domain Programming Language: C djbfft is an extremely fast library for floating-point convolution. The current version holds most of the speed records for double-precision FFTs on general-purpose computers. . djbfft provides power-of-2 complex FFTs, real FFTs at twice the speed, and fast multiplication of complex arrays. Single precision and double precision are equally supported. Paul Wise schrieb:
owner 477806 fabian@debian-unofficial.org thanks
owner 477806 pkg-multimedia-maintainers@lists.alioth.debian.org thanks I have prepared packages in the pkg-multimedia SVN. However, since ATM no other package than a52dec seems to benefit from this library, I am still reluctant to upload it to Debian...
Hi there. Is there any progress on this? Any updates? Thanks for any information, Rogério Brito.
Rogerio Brito <rbrito@ime.usp.br> writes: Is there a package that actually and actually benefits from djbfft?
Hi. I'm not sure right now, but I think that some functions of lame (OK, not packaged in Debian) and lossywav (still not packaged) might benefit from a Fast Fourier Transform. Regards,
Rogério Brito schrieb: I have prepared djbft packages in the pkg-multimedia SVN that are ready for upload IMHO. I packaged the software mainly for use with a52dec, which is the only software that I know that actually uses djbfft. However, there are several other FFT libraries already available in the Debian archive and I did not find it appropriate to upload just another one that is used by only one other software in Debian (that is - by the way - more and more replaced by generic solutions in ffmpeg). AFAIK lame does not use djbfft or any other external library for FFT calculations; the same is true for lossywav. Cheers, Fabian
Hi, Fabian. Nice to know that. Oh, just one thing (I have not checked the svn repo yet): are you compiling djbfft as a shared object? Well, I'm not sure how the fft libraries perform these days, but I think that doing a small benchmark would be useful. Especially for arches that are less popular, like ppc. Sure, lame does not use, but I'm thinking of getting rid of the assembly specific parts (as much as I can---see the executable stacks problems that we had recently). BTW, can you check out the lame CVS repo and criticize the Debian packaging? I'm willing to make major surgeries there, now that we're in plain development cycle of lame 3.99. OK, back to the djbfft, lossywav is only implemented in pascal/delphi and I am planning a C port of it, where I would need a FFT library (to avoid reinventing the wheel). Would you like to join forces and transcribe the code from pascal to C, so that we can have lossywav working for a broad range of platforms? I can add you to the sf.net project (named lossywav, of course). Regards, Rogério Brito.
Rogério Brito schrieb: onject (and it works fine), but I decided against it because (1) the djbfft code is not going to change and the API is stable anyway so static linking should be just fine and (2) djbfft is chosen for its high performance and dynamic linking would be a drawback in this regard. So I decided for building static libraries (the "normal" one and an additional PIC-flavour), but this is subject to change. Please check out: svn://svn.debian.org/svn/pkg-multimedia/unstable/djbfft Yes, sure, why not! This will be highly appreciated among distributors, I believe (given that the performance drawbacks aren't too severe). I'll see if I can find some spare time this week... Hm, not at the moment, sorry. I am not that much interested in lossywav... Cheers, Fabian
Heya So are you going to upload gjbfft to debian? Because a52dec is out of sync in Ubuntu. We have applied a patch which simply removes the silly warning "No accelerated IMDCT transform found" #441693 So do you want help with gjbfft? Or is there really no point in having it in the archive. Or would you consider applying patch to a52dec to remove the warning? BTW do you want help with a52dec? Eg. fix lintian warnings, libtoolize and convert to DEB5, DEB3, quilt, dh7 or CDBS etc Cause I have a little bit of time to do this. (I'll send git format-patches)
Am 02.12.2009 03:53, schrieb Dmitrijs Ledkovs: No, not really. I have prepared packages in our SVN repo [1], but I think it's unreasonable to upload just another library package to Debian for the sole purpose of fixing a warning in another library. [1] <http://svn.debian.org/wsvn/pkg-multimedia/unstable/djbfft/> I'd favour actually fixing it, though. Simply removing a warning is not a method I would consider valid to get rid of it. Well, at the moment I am the only (active) maintainer for a52dec in Debian, but my interest in the package could be more vivid, I admit. I'd highly appreciate if you could help out a bit and bring the package to the newest packaging standards. That sounds perfect, because the packaging is actually tracked in our GIT repository at [2] now. To work on the package I highly recommend you to apply as a member of the pkg-multimedia team on Alioth. [2] <http://git.debian.org/?p=pkg-multimedia/a52dec.git;a=summary> Cheers, Fabian
retitle 477806 RFP: djbfft -- extremely fast library for floating-point convolution noowner 477806 thanks Hi, This is an automatic email to change the status of djbfft back from ITP (Intent to Package) to RFP (Request for Package), because this bug hasn't seen any activity during the last 6 months. If you are still interested in adopting djbfft, please send a mail to <control@bugs.debian.org> with: retitle 477806 ITP: djbfft -- extremely fast library for floating-point convolution owner 477806 ! thanks However, it is not recommended to keep ITP for a long time without acting on the package, as it might cause other prospective maintainers to refrain from packaging that software. It is also a good idea to document your progress on this ITP from time to time, by mailing <477806@bugs.debian.org>. Thank you for your interest in Debian,