Thread: Re: [ReZound-users] rezound not working at all. PERIOD. (Page 2)
Status: Beta
Brought to you by:
ddurham
From: Davy D. <ddu...@da...> - 2005-07-02 17:48:26
|
Great glad it's working.. that issue really is the bane of fftw's existance (if it even has a bane).. but it's a great library and I'm sure that using floats was perhaps an afterthought-hack in order to make things faster if desired over accuracy. I dunno.. perhaps fftw-3 doesn't have this problem.. either way, rezound probably needs a setting.. I remember trying to figure out a while back how to detect how it was compiled and have rezound build accordingly or something like that.. but didn't figure out a good way to do it. Things get even more complicated when ladspa plugins that use fftw come already compiled the wrong way.. so watch out for that if you ever use a laspa plugin (which likely uses fftw) that causes rezound to segv.. derek holzer wrote: > Yup, that was it. I manually compiled FFTW 2.1.5, recompiled the > Rezound-CVS and everything looks good. I'll have to check the Gentoo > ebuild and see what flags are being passed to FFTW. > > thanks for all your help! > derek > > > > Davy Durham wrote: > >> Ok this may in fact be a clue.. >> >> As for whether fftw2 or 3... version 3 is a whole new API than >> version 2.. so I really doubt that distroes will stop including >> version 2. They're really two separate libraries with the same >> name. However I probably should look at reimplementing some things >> so that version 3 is supported, but it is very low priority since >> version 2 is still being maintained. see http://fftw.org >> >> Now another issue.. fftw can be compiled with it's native datatype >> being either 32bit floats or 64bit doubles (but not both in the same >> libfftw.so) ReZound may be expecting fftw to be using floats and >> you're lib may be compiled using doubles (or vice-versa). If they >> don't match, then a segv is probably likely. >> >> >> It probably ought to be an option in rezound to specify how fftw was >> built. However in the mean time you should be able to compile fftw >> yourself and ensure that they're both using the same data type.. I >> think if you compile fftw with no special configure flags then it >> builds as double, and likewise rezound expects doubles. >> >> Your distro's package might come with both float and double >> versions.. sometimes the package might contain two .so files: >> libfftwd.so and libfftws.so (double and single versions) But a >> symlink libfftw.so points to one of them (maybe the wrong one) and >> rezound looks for libfftw.so >> >> >> Hopefully this may be it.. >> >> -- Davy >> >> >> >> derek holzer wrote: >> >>> OK, think I found it: >>> >>> (gdb) run >>> Starting program: /usr/local/bin/rezound >>> warning: Unable to find dynamic linker breakpoint function. >>> GDB will be unable to debug shared library initializers >>> and track explicitly loaded dynamic code. >>> [Thread debugging using libthread_db enabled] >>> [New Thread 16384 (LWP 1440)] >>> using path '/usr/local/share/rezound' for share data directory >>> [New Thread 32769 (LWP 1443)] >>> [New Thread 16386 (LWP 1444)] >>> If rezound dies unexpectedly while seeking with the >>> keyboard, auto-repeat may be disabled.. if this happens run >>> 'rezound --fix-auto-repeat' >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to Thread 16384 (LWP 1440)] >>> 0xb758a819 in fftw_real2hc_32 () from /usr/lib/libdrfftw.so.2 >>> (gdb) bt >>> #0 0xb758a819 in fftw_real2hc_32 () from usr/lib/libdrfftw.so.2 >>> (gdb) cont >>> Continuing. >>> Cannot find thread 16384: generic error >>> >>> >>> I had FFTW 3.0.1-r1 installed, so I downgraded to FFTW 2.1.5, but I >>> still get the same segfault. I did make sure to clean out any traces >>> of the 3.0.1 version, and also recompiled Rezound-CVS against the >>> 2.1.5 version. Is there a FFTW specific version I should be using? >>> >>> * sci-libs/fftw >>> Latest version available: 3.0.1-r1 >>> Latest version installed: 2.1.5-r1 >>> Size of downloaded files: 1,900 kB >>> Homepage: http://www.fftw.org/ >>> Description: C subroutine library for computing the Discrete >>> Fourier Transform (DFT) >>> License: GPL-2 >>> >>> So I've figured out what the problem is, but I'm still just as >>> confused as before why it still segfaults. Further suggestions? >>> >>> Also, since FFTW 3 is now the stable version for Gentoo, I expect a >>> lot more folks out there will have trouble with Rezound. >>> >>> derek >>> >>> >>> Davy Durham wrote: >>> >>>> No, I can't say that anything in that list should cause a problem.. >>>> >>>> gdb is breaking on SIG32 events.. but those are not the crash.. do >>>> 'cont' commands in gdb until you get actually a SEGV signal .. that >>>> will be your segfault and perhaps reveal more on the backtrace. >>>> Also make sure that rezound is being built with -g on the c++ >>>> command lines so that debug info is compiled in.. If it's not, >>>> "make clean" and perhaps run "CXXFLAGS=-g configure ..." >>> >>> >>> >>> >>> >>> >> >> > > |
From: John O. <jo...@mc...> - 2005-07-02 23:15:04
|
Derek, I have regular Gentoo ~amd64 installs of: fftw-2.1.5-r1 fftw-3.0.1-r1 on my system, and so far, I have had no problems. Now that I mention this, I no doubt will. John On Saturday 02 July 2005 01:10 pm, derek holzer wrote: > Yup, that was it. I manually compiled FFTW 2.1.5, recompiled the > Rezound-CVS and everything looks good. I'll have to check the Gentoo > ebuild and see what flags are being passed to FFTW. > > derek |