Thread: [ReZound-users] Progress report
Status: Beta
Brought to you by:
ddurham
From: John O. <jo...@mc...> - 2005-10-10 22:30:17
|
Davy, Apparently the problem I was having with ReZound segfaulting on loading was due to problems in my Gentoo installation. It has taken me nearly 3 weeks to get a stable Gentoo install, largely due to the hardened USE flag, which I have now unset. At the moment I can load ReZound, load a wav file into it, edit it, but if I try to play the file ReZound segfaults, regardless of whether I use Gentoo portage to install ReZound or I install it from CVS. gcdmaster and xmms will correctly play the same wav file. I have previously gotten ReZound to work on an AMD64 bit system, running in 64 bit mode. However, that no longer seems so easy. Any thoughts on what might be wrong? It is not a very critical problem, since I have ReZound installed on a Knoppix disk, so I can reboot any time I need to use it. Eventually I would like to get back to having all my sound editing stuff on a single machine though. Thanks again for those great crossfades, John |
From: Davy D. <dd...@us...> - 2005-10-11 04:21:27
|
John Ouzts wrote: > >Any thoughts on what might be wrong? It is not a very critical problem, since >I have ReZound installed on a Knoppix disk, so I can reboot any time I need >to use it. Eventually I would like to get back to having all my sound editing >stuff on a single machine though. > > > What audio output method are you using? ALSA, OSS, JACK, PortAudio, etc?.. see rezound --help to force it to try a particular one first. ~/.rezound/registry.dat dictates the order otherwise. |
From: John O. <jo...@mc...> - 2005-10-14 18:40:29
|
On Tuesday 11 October 2005 12:21 am, Davy Durham wrote: > John Ouzts wrote: > >Any thoughts on what might be wrong? It is not a very critical problem, > > since I have ReZound installed on a Knoppix disk, so I can reboot any > > time I need to use it. Eventually I would like to get back to having all > > my sound editing stuff on a single machine though. > > What audio output method are you using? ALSA, OSS, JACK, PortAudio, > etc?.. see rezound --help to force it to try a particular one first. > ~/.rezound/registry.dat dictates the order otherwise. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > ------------------------------------------------------- > ReZound-users mailing list > ReZ...@li... > Subscribe/Unsubscribe and change options > https://lists.sourceforge.net/lists/listinfo/rezound-users > ReZound-users mailing list archive > http://sourceforge.net/mailarchive/forum.php?forum=rezound-users Davy, Sorry to take so long in replying to your very kind inquiry. The default audio-method is alsa. I get a warning: ALSA used different sample rate (48000)...... message which verifies it is trying to use alsa. I have also tried oss and portaudio. I believe oss emulation is available -- at least snd_pcm_oss module is loaded. Neither oss or portaudio stops ReZound from segfaulting when the play button is pressed. When I start jack (commandline or qjackctl) and try --audio-method=jack, I get: Error occured while initializing audio method 'jack' --- virtual void CJACKSoundPlayer::initialize() --- error connecting to jack server -- jack server not running? The jack server is running according to ps -edalf, however. xmms continues to work fine, although I don't know which audio-method it is actually using. When I boot the same machine with a 32 bit Knoppix CD-ROM, rezound (installed via apt-get) works fine. I have a second Gentoo AMD64 machine where I separately compiled and separately fully installed both the CVS and the Gentoo ebuild versions of ReZound. In both cases ReZound segfaults when the play button is pressed. Here is a current list of libraries in case an updated version of one of these is where the problem lies: libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00002aaaaabc1000) libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x00002aaaaacd6000) libjack.so.0 => /usr/lib/libjack.so.0 (0x00002aaaaae01000) libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0x00002aaaaaf0e000) libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00002aaaab015000) libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00002aaaab2f5000) libogg.so.0 => /usr/lib/libogg.so.0 (0x00002aaaab420000) libFLAC++.so.4 => /usr/lib/libFLAC++.so.4 (0x00002aaaab525000) libFLAC.so.6 => /usr/lib/libFLAC.so.6 (0x00002aaaab645000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/libstdc++.so.6 (0x00002aaaab782000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/libgcc_s.so.1 (0x00002aaaab972000) libFOX-1.2.so.0 => /usr/lib/libFOX-1.2.so.0 (0x00002aaaaba7e000) libXft.so.2 => /usr/lib/libXft.so.2 (0x00002aaaabefa000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00002aaaac00e000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00002aaaac142000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x00002aaaac2d4000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00002aaaac3f8000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00002aaaac502000) libpng.so.3 => /usr/lib/libpng.so.3 (0x00002aaaac60c000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x00002aaaac744000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00002aaaac89b000) libz.so.1 => /lib/libz.so.1 (0x00002aaaac9bc000) libbz2.so.1 => /lib/libbz2.so.1 (0x00002aaaacad0000) libcups.so.2 => /usr/lib/libcups.so.2 (0x00002aaaacbe0000) libnsl.so.1 => /lib/libnsl.so.1 (0x00002aaaaccff000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00002aaaace15000) libGL.so.1 => /usr/lib64/opengl/xorg-x11/lib/libGL.so.1 (0x00002aaaacf9a000) libSM.so.6 => /usr/lib/libSM.so.6 (0x00002aaaad144000) libICE.so.6 => /usr/lib/libICE.so.6 (0x00002aaaad24e000) libXmu.so.6 => /usr/lib/libXmu.so.6 (0x00002aaaad369000) libXt.so.6 => /usr/lib/libXt.so.6 (0x00002aaaad481000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00002aaaad5e3000) libXi.so.6 => /usr/lib/libXi.so.6 (0x00002aaaad6f5000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00002aaaad7fd000) libdrfftw.so.2 => /usr/lib/libdrfftw.so.2 (0x00002aaaad9dc000) libdfftw.so.2 => /usr/lib/libdfftw.so.2 (0x00002aaaadb0f000) libportaudio.so => /usr/lib/libportaudio.so (0x00002aaaadc47000) libasound.so.2 => /usr/lib/libasound.so.2 (0x00002aaaadd4e000) libdl.so.2 => /lib/libdl.so.2 (0x00002aaaadf1f000) libm.so.6 => /lib/tls/libm.so.6 (0x00002aaaae022000) libc.so.6 => /lib/tls/libc.so.6 (0x00002aaaae1a8000) /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x00002aaaae3ce000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x00002aaaae505000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00002aaaae741000) Is anyone else trying to run ReZound on a 64 bit machine? Many thanks, John |
From: derek h. <de...@x-...> - 2005-10-14 19:51:42
|
Hi John, John Ouzts wrote: > I have a second Gentoo AMD64 machine where I > separately compiled and separately fully installed both the CVS and the > Gentoo ebuild versions of ReZound. In both cases ReZound segfaults when the > play button is pressed. I went around and a round for a week with Rezound segfaulting on Gentoo, until I worked out that it was compiled against the wrong FFTW library. On Gentoo, you'll need to make sure it uses FFTW 2.1.5. You can install FFTW 3 afterward the compile so long as it doesn't get rid of the FFTW 2.1.5 shared objects. That's what worked for me at least. Ideally, Rezound would support the latest FFTW (which is what most distros use by default by now, I imagine). d. -- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 142: "Shut the door and listen from outside" |
From: Davy D. <dd...@us...> - 2005-10-15 06:08:23
|
I'm *really* surprised that you wouldn't get compiler/linker errors if rezound was trying to link to fftw3 since tons of API changed in v3 and rezound even checks for v2 if I'm remember correctly. However, when fftw is built, you can choose to compile it to use floats or doubles (32bit vs 64bit floating-point types) Unfortunately, the library is named the same way whichever way you do it. Thus, if rezound expects doubles and the fftw lib was configured to use floats, then segfaults would likely occur. I believe fftw v2 builds for doubles by default. If the lib was built with the configure flag --enable-float, rezound has know way of knowing that and will link against the lib expecting doubles and segfaults will ensue. I guess rezound could have a configure flag to change the way it expects fftw to be linked, but you'd still have to know which way the lib was built and either rebuilt it, or rebuilt rezound (with the flag). Worse, sometimes LADSPA plugins that use fftw expect it opposite of rezound and that will cause segfaults as well, but it'll just seem as though the ladspa plugin has a bug or something. I don't even know if the new fftw v3 fixes this issue.. it's really just a packaging issue more than their code. Although, it's really an annoying way for them to give the choice and not change the libname to something like libfftwf.a/so and libfftwd.a/so (which is the way some distroes package it actually). Anyway.. try looking into that John.. Check how fftw v2 is being configured in the emerge. Thanks, Davy derek holzer wrote: > Hi John, > > John Ouzts wrote: > >> I have a second Gentoo AMD64 machine where I separately compiled and >> separately fully installed both the CVS and the Gentoo ebuild >> versions of ReZound. In both cases ReZound segfaults when the play >> button is pressed. > > > I went around and a round for a week with Rezound segfaulting on > Gentoo, until I worked out that it was compiled against the wrong FFTW > library. On Gentoo, you'll need to make sure it uses FFTW 2.1.5. You > can install FFTW 3 afterward the compile so long as it doesn't get rid > of the FFTW 2.1.5 shared objects. > > That's what worked for me at least. Ideally, Rezound would support the > latest FFTW (which is what most distros use by default by now, I > imagine). > > d. > |
From: John O. <jo...@mc...> - 2005-10-15 16:51:50
|
On Saturday 15 October 2005 02:07 am, Davy wrote: > I'm *really* surprised that you wouldn't get compiler/linker errors if > rezound was trying to link to fftw3 since tons of API changed in v3 and > rezound even checks for v2 if I'm remember correctly. > > However, when fftw is built, you can choose to compile it to use floats > or doubles (32bit vs 64bit floating-point types) Unfortunately, the > library is named the same way whichever way you do it. Thus, if rezound > expects doubles and the fftw lib was configured to use floats, then > segfaults would likely occur. > > I believe fftw v2 builds for doubles by default. If the lib was built > with the configure flag --enable-float, rezound has know way of knowing > that and will link against the lib expecting doubles and segfaults will > ensue. I guess rezound could have a configure flag to change the way > it expects fftw to be linked, but you'd still have to know which way the > lib was built and either rebuilt it, or rebuilt rezound (with the flag). > > Worse, sometimes LADSPA plugins that use fftw expect it opposite of > rezound and that will cause segfaults as well, but it'll just seem as > though the ladspa plugin has a bug or something. > > I don't even know if the new fftw v3 fixes this issue.. it's really just > a packaging issue more than their code. Although, it's really an > annoying way for them to give the choice and not change the libname to > something like libfftwf.a/so and libfftwd.a/so (which is the way some > distroes package it actually). > > Anyway.. try looking into that John.. Check how fftw v2 is being > configured in the emerge. > > Thanks, > Davy > > derek holzer wrote: > > Hi John, > > > > John Ouzts wrote: > >> I have a second Gentoo AMD64 machine where I separately compiled and > >> separately fully installed both the CVS and the Gentoo ebuild > >> versions of ReZound. In both cases ReZound segfaults when the play > >> button is pressed. > > > > I went around and a round for a week with Rezound segfaulting on > > Gentoo, until I worked out that it was compiled against the wrong FFTW > > library. On Gentoo, you'll need to make sure it uses FFTW 2.1.5. You > > can install FFTW 3 afterward the compile so long as it doesn't get rid > > of the FFTW 2.1.5 shared objects. > > > > That's what worked for me at least. Ideally, Rezound would support the > > latest FFTW (which is what most distros use by default by now, I > > imagine). > > > > d. Many thanks to Derek and Davy. I have the following installed on my machine: fftw-2.1.5-r1 fftw-3.0.1-r2 Here is the complete ebuild for rezound, which calls for fftw v2: # Copyright 1999-2005 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/media-sound/rezound/rezound-0.12.0_beta.ebuild,v 1.3 2005/09/09 13:19:09 flameeyes Exp $ inherit eutils MY_P="${P/_/}" S="${WORKDIR}/${MY_P}" DESCRIPTION="Sound editor and recorder" HOMEPAGE="http://rezound.sourceforge.net" SRC_URI="mirror://sourceforge/${PN}/${MY_P}.tar.gz" LICENSE="GPL-2" SLOT="0" KEYWORDS="amd64 ~ppc x86" IUSE="16bittmp alsa flac jack nls oss portaudio soundtouch vorbis" RDEPEND="virtual/x11 =sci-libs/fftw-2* >=x11-libs/fox-1.2.4 >=media-libs/audiofile-0.2.3 >=media-libs/ladspa-sdk-1.12 >=media-libs/ladspa-cmt-1.15 alsa? ( >=media-libs/alsa-lib-1.0 ) flac? ( >=media-libs/flac-1.1.0 ) jack? ( media-sound/jack-audio-connection-kit ) portaudio? ( >=media-libs/portaudio-18 ) soundtouch? ( >=media-libs/libsoundtouch-1.2.1 ) vorbis? ( media-libs/libvorbis media-libs/libogg )" # optional packages (don't need to be installed during emerge): # # >=media-sound/lame-3.92 # app-cdr/cdrdao DEPEND="${RDEPEND} sys-devel/autoconf sys-devel/automake sys-devel/bison sys-devel/flex" src_compile() { # fix compilation errors on ppc, where some # of the required functions aren't defined #test "${ARCH}" = ppc && epatch ${FILESDIR}/undefined-functions.patch # following features can't be disabled if already installed: # -> flac, oggvorbis, soundtouch local sampletype="" use 16bittmp && sampletype="--enable-internal-sample-type=int16" use 16bittmp || sampletype="--enable-internal-sample-type=float" econf \ $(use_enable alsa) \ $(use_enable jack) \ $(use_enable nls) \ $(use_enable oss) \ $(use_enable portaudio) \ ${sampletype} \ --enable-ladspa \ --enable-largefile \ || die "configure failed" emake || die "make failed" } src_install() { make DESTDIR="${D}" install || die "make install failed" # remove wrong doc directory rm -rf ${D}/usr/doc/${PN} dodoc docs/{AUTHORS,NEWS,README*} dodoc docs/{TODO_FOR_USERS_TO_READ,*.txt} docinto code dodoc docs/code/* } Following Derek's advice, I unmerged fftw-3.0.1-r2 and ReZound 0.12.0, and re-emerged ReZound without fftw-3.0.1-r2 on the machine. Unfortunately it still segfaults on pressing the Play button. So I unmerged ReZound again, and got a fresh copy of the source from CVS. After bootstrap,configure,make and make install, it segfaults on pressing the Play button. Next I tracked down the amd64-compatible ebuild for fftw-2.1.5-r1. It says: pkg_setup() { einfo "" einfo "This ebuild installs double and single precision versions of library" einfo "This involves some name mangling, as supported by package and required" einfo "by some apps that use it." einfo "By default, the symlinks to non-mangled names will be created off" einfo "double-precision version. In order to symlink to single-precision use" einfo "SINGLE=yes emerge fftw" einfo "" } Just to rule out that it had ever been compiled for singles, I unmerged and re-emerged it. Again ReZound segfaults on pressing the Play button. So sadly there is no joy in Muddville. Thanks again, John |
From: Derek H. <de...@x-...> - 2005-10-15 17:36:59
|
Hi John, Quoting John Ouzts <jo...@mc...>: > Just to rule out that it had ever been compiled for singles, I unmerged and > re-emerged it. Again ReZound segfaults on pressing the Play button. So sadly > there is no joy in Muddville. Sorry there's no joy yet. I wasn't using 64bit, but I was getting the exact same problems you are having on a 64bit processor running 32bit. You might search the archives of this list and follow through my original thread to see if anything else strikes you. You should also try running a traceback with gdb and posting that info here (for Davy's edification, not mine!). At least then you might get a closer idea what the issue is. best, d. -- http://umatic.nl http://soundtransit.nl |
From: Davy D. <dd...@us...> - 2005-10-16 00:18:22
|
Not being very familiar with gentoo, I can't tell from that how fftw2 is being configured.. Try unemerging any version of fftw and downloading fftw v2's source and configure yourself just to rule this in or out as being the problem. You shouldn't need any special configure flags when you configure fftw.. then either download rezound yourself or emerge it.. However, your stack trace that you sent me doesn't look to be having the problem related to fftw, but, when you're talking about stack corruption, it could still be fftw corrupting the stack (because the type sizes are wrong) and the real fireworks don't show up till later. -- Davy John Ouzts wrote: >On Saturday 15 October 2005 02:07 am, Davy wrote: > > >>I'm *really* surprised that you wouldn't get compiler/linker errors if >>rezound was trying to link to fftw3 since tons of API changed in v3 and >>rezound even checks for v2 if I'm remember correctly. >> >>However, when fftw is built, you can choose to compile it to use floats >>or doubles (32bit vs 64bit floating-point types) Unfortunately, the >>library is named the same way whichever way you do it. Thus, if rezound >>expects doubles and the fftw lib was configured to use floats, then >>segfaults would likely occur. >> >>I believe fftw v2 builds for doubles by default. If the lib was built >>with the configure flag --enable-float, rezound has know way of knowing >>that and will link against the lib expecting doubles and segfaults will >>ensue. I guess rezound could have a configure flag to change the way >>it expects fftw to be linked, but you'd still have to know which way the >>lib was built and either rebuilt it, or rebuilt rezound (with the flag). >> >>Worse, sometimes LADSPA plugins that use fftw expect it opposite of >>rezound and that will cause segfaults as well, but it'll just seem as >>though the ladspa plugin has a bug or something. >> >>I don't even know if the new fftw v3 fixes this issue.. it's really just >>a packaging issue more than their code. Although, it's really an >>annoying way for them to give the choice and not change the libname to >>something like libfftwf.a/so and libfftwd.a/so (which is the way some >>distroes package it actually). >> >>Anyway.. try looking into that John.. Check how fftw v2 is being >>configured in the emerge. >> >>Thanks, >> Davy >> >>derek holzer wrote: >> >> >>>Hi John, >>> >>>John Ouzts wrote: >>> >>> >>>>I have a second Gentoo AMD64 machine where I separately compiled and >>>>separately fully installed both the CVS and the Gentoo ebuild >>>>versions of ReZound. In both cases ReZound segfaults when the play >>>>button is pressed. >>>> >>>> >>>I went around and a round for a week with Rezound segfaulting on >>>Gentoo, until I worked out that it was compiled against the wrong FFTW >>>library. On Gentoo, you'll need to make sure it uses FFTW 2.1.5. You >>>can install FFTW 3 afterward the compile so long as it doesn't get rid >>>of the FFTW 2.1.5 shared objects. >>> >>>That's what worked for me at least. Ideally, Rezound would support the >>>latest FFTW (which is what most distros use by default by now, I >>>imagine). >>> >>>d. >>> >>> > >Many thanks to Derek and Davy. > >I have the following installed on my machine: > >fftw-2.1.5-r1 >fftw-3.0.1-r2 > >Here is the complete ebuild for rezound, which calls for fftw v2: > ># Copyright 1999-2005 Gentoo Foundation ># Distributed under the terms of the GNU General Public License v2 ># >$Header: /var/cvsroot/gentoo-x86/media-sound/rezound/rezound-0.12.0_beta.ebuild,v >1.3 2005/09/09 13:19:09 flameeyes Exp $ > >inherit eutils > >MY_P="${P/_/}" >S="${WORKDIR}/${MY_P}" > >DESCRIPTION="Sound editor and recorder" >HOMEPAGE="http://rezound.sourceforge.net" >SRC_URI="mirror://sourceforge/${PN}/${MY_P}.tar.gz" > >LICENSE="GPL-2" >SLOT="0" >KEYWORDS="amd64 ~ppc x86" >IUSE="16bittmp alsa flac jack nls oss portaudio soundtouch vorbis" > >RDEPEND="virtual/x11 > =sci-libs/fftw-2* > >=x11-libs/fox-1.2.4 > >=media-libs/audiofile-0.2.3 > >=media-libs/ladspa-sdk-1.12 > >=media-libs/ladspa-cmt-1.15 > alsa? ( >=media-libs/alsa-lib-1.0 ) > flac? ( >=media-libs/flac-1.1.0 ) > jack? ( media-sound/jack-audio-connection-kit ) > portaudio? ( >=media-libs/portaudio-18 ) > soundtouch? ( >=media-libs/libsoundtouch-1.2.1 ) > vorbis? ( media-libs/libvorbis media-libs/libogg )" > ># optional packages (don't need to be installed during emerge): ># ># >=media-sound/lame-3.92 ># app-cdr/cdrdao > >DEPEND="${RDEPEND} > sys-devel/autoconf > sys-devel/automake > sys-devel/bison > sys-devel/flex" > >src_compile() { > # fix compilation errors on ppc, where some > # of the required functions aren't defined > #test "${ARCH}" = ppc && epatch ${FILESDIR}/undefined-functions.patch > > # following features can't be disabled if already installed: > # -> flac, oggvorbis, soundtouch > local sampletype="" > use 16bittmp && sampletype="--enable-internal-sample-type=int16" > use 16bittmp || sampletype="--enable-internal-sample-type=float" > > econf \ > $(use_enable alsa) \ > $(use_enable jack) \ > $(use_enable nls) \ > $(use_enable oss) \ > $(use_enable portaudio) \ > ${sampletype} \ > --enable-ladspa \ > --enable-largefile \ > || die "configure failed" > > emake || die "make failed" >} > >src_install() { > make DESTDIR="${D}" install || die "make install failed" > > # remove wrong doc directory > rm -rf ${D}/usr/doc/${PN} > dodoc docs/{AUTHORS,NEWS,README*} > dodoc docs/{TODO_FOR_USERS_TO_READ,*.txt} > > docinto code > dodoc docs/code/* >} > >Following Derek's advice, I unmerged fftw-3.0.1-r2 and ReZound 0.12.0, and >re-emerged ReZound without fftw-3.0.1-r2 on the machine. Unfortunately it >still segfaults on pressing the Play button. > >So I unmerged ReZound again, and got a fresh copy of the source from CVS. >After bootstrap,configure,make and make install, it segfaults on pressing the >Play button. > >Next I tracked down the amd64-compatible ebuild for fftw-2.1.5-r1. It says: > >pkg_setup() { > einfo "" > einfo "This ebuild installs double and single precision versions of library" > einfo "This involves some name mangling, as supported by package and >required" > einfo "by some apps that use it." > einfo "By default, the symlinks to non-mangled names will be created off" > einfo "double-precision version. In order to symlink to single-precision use" > einfo "SINGLE=yes emerge fftw" > einfo "" >} > >Just to rule out that it had ever been compiled for singles, I unmerged and >re-emerged it. Again ReZound segfaults on pressing the Play button. So sadly >there is no joy in Muddville. > >Thanks again, > >John > > >------------------------------------------------------- >This SF.Net email is sponsored by: >Power Architecture Resource Center: Free content, downloads, discussions, >and more. http://solutions.newsforge.com/ibmarch.tmpl >------------------------------------------------------- >ReZound-users mailing list >ReZ...@li... >Subscribe/Unsubscribe and change options >https://lists.sourceforge.net/lists/listinfo/rezound-users >ReZound-users mailing list archive >http://sourceforge.net/mailarchive/forum.php?forum=rezound-users > > |