Thread: [ReZound-users] TEST: New Audio Output Code
Status: Beta
Brought to you by:
ddurham
From: Davy D. <dd...@us...> - 2004-04-02 04:18:27
Attachments:
new_audio_output.patch
|
To anyone out there successfully compiling from CVS... I've attached a patch file that contains some new audio output code I've been working on. I'm rewriting it to be more JACK compliant (it's not yet, but it's a huge step in that direction). It pretty much does all audio output buffer in a entirely new way. So it needs much testing. If you're up to it, I'd appriciate any feed back as far as problems, crashes, lockups etc. I would suggest making a copy of your currently checked out tree, then apply the patch to the copy. To apply the patch, save it in top directory of the rezound source tree. Then run 'patch < new_audio_output.patch'. Please let me know if you have any problem. To anyone out there not already compiling from CVS.. It's not easy. My hat is off to anyone who has succeeded (simply because the autotool are so precarious most of the time). But if you're up to trying it, feel free. This is one of the things that I wanted to complete before the next release. Also! note that if you run from CVS, I've made some changes that save the .rez files in such a way that 0.9.0beta and older will not be able to open them. So you might want to use another format besides .rez or just don't save anything too important with .rez right now. This new code affects (among other things)... - playing - playing looped - changing selection positions while playing looped or playing selection only (that cause the play position to be interrupted or moved) - playing looped with gap skip or tone between loops - changing play speed while playing etc - and all combinations of such Thanks, Davy |
From: Andrew G. <a...@et...> - 2004-04-04 00:29:46
|
Davy, I have played (my mouse was hot :-) with new playing out, and have not noticed any glitches. Andrew ======= On Friday 02 April 2004 8:18, Davy Durham wrote: ======= ... This new code affects (among other things)... - playing - playing looped - changing selection positions while playing looped or playing selection only (that cause the play position to be interrupted or moved) - playing looped with gap skip or tone between loops - changing play speed while playing etc - and all combinations of such Thanks, Davy |
From: Jack O'Q. <jo...@io...> - 2004-04-08 16:36:27
|
Davy Durham <dd...@us...> writes: > To anyone out there not already compiling from CVS.. It's not easy. > My hat is off to anyone who has succeeded (simply because the autotool > are so precarious most of the time). But if you're up to trying it, > feel free. Wanting to try this patch, I checked out a copy of CVS. I tried to follow the instructions in doc/CVS-INSTALL. My tool chain is up-to-date, AFAICT. Here's what I get running ./bootstrap... autoconf-wrapper: unrecognized option -fisv autoreconf2.50: working in `.' autoreconf2.50: running: aclocal -I config/m4 --output=aclocal.m4t autoreconf2.50: `aclocal.m4' is unchanged autoreconf2.50: running: gettextize --force Symlinking file ABOUT-NLS Symlinking file config/config.rpath Symlinking file config/mkinstalldirs Not copying intl/ directory. Symlinking file po/Makefile.in.in Symlinking file po/Makevars.template Symlinking file po/Rules-quot Symlinking file po/boldquot.sed Symlinking file po/en@boldquot.header Symlinking file po/en@quot.header Symlinking file po/insert-header.sin Symlinking file po/quot.sed Symlinking file po/remove-potcdate.sin Symlinking file config/m4/codeset.m4 Symlinking file config/m4/gettext.m4 Symlinking file config/m4/glibc21.m4 Symlinking file config/m4/iconv.m4 Symlinking file config/m4/intdiv0.m4 Symlinking file config/m4/intmax.m4 Symlinking file config/m4/inttypes.m4 Symlinking file config/m4/inttypes_h.m4 Symlinking file config/m4/inttypes-pri.m4 Symlinking file config/m4/isc-posix.m4 Symlinking file config/m4/lcmessage.m4 Symlinking file config/m4/lib-ld.m4 Symlinking file config/m4/lib-link.m4 Symlinking file config/m4/lib-prefix.m4 Symlinking file config/m4/longdouble.m4 Symlinking file config/m4/longlong.m4 Symlinking file config/m4/nls.m4 Symlinking file config/m4/po.m4 Symlinking file config/m4/printf-posix.m4 Symlinking file config/m4/progtest.m4 Symlinking file config/m4/signed.m4 Symlinking file config/m4/size_max.m4 Symlinking file config/m4/stdint_h.m4 Symlinking file config/m4/uintmax_t.m4 Symlinking file config/m4/ulonglong.m4 Symlinking file config/m4/wchar_t.m4 Symlinking file config/m4/wint_t.m4 Symlinking file config/m4/xsize.m4 Please use AM_GNU_GETTEXT([external]) in order to cause autoconfiguration to look for an external libintl. Please update po/Makevars so that it defines all the variables mentioned in po/Makevars.template. You can then remove po/Makevars.template. Please run 'aclocal -I config/m4' to regenerate the aclocal.m4 file. You need aclocal from GNU automake 1.5 (or newer) to do this. Then run 'autoconf' to regenerate the configure file. You might also want to copy the convenience header file gettext.h from the /usr/share/gettext directory into your package. It is a wrapper around <libintl.h> that implements the configure --disable-nls option. Press Return to acknowledge the previous four paragraphs. autoreconf2.50: running: libtoolize --force Putting files in AC_CONFIG_AUX_DIR, `config'. autoreconf2.50: running: automake --add-missing --foreign --add-missing --force-missing configure.ac:28: required file `././config/config.h.in' not found autoreconf2.50: running: autoconf --force configure.ac:31: error: possibly undefined macro: AC_GNU_SOURCE autoreconf2.50: autoconf failed with exit status: 1 at /usr/bin/autoreconf2.50 line 378 -- joq |
From: Davy D. <dd...@us...> - 2004-04-08 17:53:43
|
On Thu, 2004-04-08 at 11:36, Jack O'Quin wrote: > autoreconf2.50: running: libtoolize --force > Putting files in AC_CONFIG_AUX_DIR, `config'. > autoreconf2.50: running: automake --add-missing --foreign --add-missing --force-missing > configure.ac:28: required file `././config/config.h.in' not found > autoreconf2.50: running: autoconf --force > configure.ac:31: error: possibly undefined macro: AC_GNU_SOURCE > autoreconf2.50: autoconf failed with exit status: 1 > at /usr/bin/autoreconf2.50 line 378 Hmm.. well I'm not exactly sure (this is REALLY one of those things you have to be on the machine to play with).. autotools are unfortunately constantly in flux, so it's really hard to tell. I have automake-1.7.9, autoconf-2.59 and gettext-0.13 installed. :-/ -- Davy |
From: Jack O'Q. <jo...@io...> - 2004-04-08 18:03:04
|
Davy Durham <dd...@us...> writes: > Hmm.. well I'm not exactly sure (this is REALLY one of those things you > have to be on the machine to play with).. autotools are unfortunately > constantly in flux, so it's really hard to tell. > > I have automake-1.7.9, autoconf-2.59 and gettext-0.13 installed. My system has... m4-1.4 autoconf-2.53 automake-1.6.3 libtool-1.5.2 pkgconfig-0.15.0 gettext-0.14.1 doc/CVS-INSTALL asks for... m4-1.4 (or higher) autoconf-2.53 (or higher) automake-1.6.3 (or higher) libtool-1.4.2 (or higher) pkgconfig-0.12.0 (or higher) gettext-0.11.5 (or higher) Is that list out of date? -- joq |
From: guenter g. <ge...@xd...> - 2004-04-08 22:26:36
|
On 8 Apr 2004, Jack O'Quin wrote: > My system has... > > m4-1.4 > autoconf-2.53 > automake-1.6.3 > libtool-1.5.2 > pkgconfig-0.15.0 > gettext-0.14.1 > > doc/CVS-INSTALL asks for... > > m4-1.4 (or higher) > autoconf-2.53 (or higher) > automake-1.6.3 (or higher) > libtool-1.4.2 (or higher) > pkgconfig-0.12.0 (or higher) > gettext-0.11.5 (or higher) > > Is that list out of date? :) Thats a good one. Considering that these tools were written to help the software developers to forget about library versions and dependencies and such, seems that they created dependencies on themselves that are even harder to maintain .... Guenter > -- > joq > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linus Tutorvalds > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > ------------------------------------------------------- > 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 > |
From: Jack O'Q. <jo...@io...> - 2004-04-08 22:32:10
|
guenter geiger <ge...@xd...> writes: > Thats a good one. Considering that these tools were written to help the > software developers to forget about library versions and dependencies and > such, seems that they created dependencies on themselves that are even > harder to maintain .... I get as frustrated as anyone with the GNU autotools. But, I keep in mind how difficult their task is and how few alternatives there are. -- joq |
From: guenter g. <ge...@xd...> - 2004-04-08 22:46:50
|
> guenter geiger <ge...@xd...> writes: > > > Thats a good one. Considering that these tools were written to help the > > software developers to forget about library versions and dependencies and > > such, seems that they created dependencies on themselves that are even > > harder to maintain .... > > I get as frustrated as anyone with the GNU autotools. But, I keep in > mind how difficult their task is and how few alternatives there are. You are definitely right. I just couldn't resist. When I saw all these version numbers it just looked so surreal. I didn't mean to blame anyone, rather taking a step back and look at it from the distance. Guenter > -- > joq > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > ------------------------------------------------------- > 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 > |
From: Jack O'Q. <jo...@io...> - 2004-04-08 18:11:23
|
Davy Durham <dd...@us...> writes: > Hmm.. well I'm not exactly sure (this is REALLY one of those things you > have to be on the machine to play with).. autotools are unfortunately > constantly in flux, so it's really hard to tell. Just realized that it is probably not worthwhile for either of us to spend much time getting rezound CVS running on my system. Probably simpler for you to build a `make dist' tarball of the new output code for me (and others) to test with. -- joq |
From: Davy D. <dd...@us...> - 2004-04-10 01:42:34
|
Jack O'Quin wrote: >Just realized that it is probably not worthwhile for either of us to >spend much time getting rezound CVS running on my system. > >Probably simpler for you to build a `make dist' tarball of the new >output code for me (and others) to test with. > > Alright, Jack has offered the use of his server.. Here's a link to the latest CVS with the audio output patch applied... http://www.joq.us/rezound/rezound-0.9.1beta_test.tar.gz |
From: Jack O'Q. <jo...@io...> - 2004-04-11 03:06:18
|
Davy Durham <dd...@us...> writes: > Alright, Jack has offered the use of his server.. Here's a link to the > latest CVS with the audio output patch applied... > > http://www.joq.us/rezound/rezound-0.9.1beta_test.tar.gz Had some trouble compiling on my Debian woody system with g++ 2.95.4. There were lots of warning messages, most but not all generated by explicit #warning directives. Then the build stopped... g++ -DHAVE_CONFIG_H -I. -I. -I../../config -I../../src/misc -I../../src/misc/missing/generated -I../../src/PoolFile -I/INSTALL/jack/include -I/INSTALL/rezound//include -I/INSTALL/rezound//include -I/INSTALL/rezound//include -I/INSTALL/rezound//include -I/INSTALL/rezound//include -g -Wall -Wno-unused -I/INSTALL/rezound//include -I/INSTALL/rezound//include -I/INSTALL/rezound//include -c CPortAudioSoundRecorder.cpp -Wp,-MD,.deps/CPortAudioSoundRecorder.TPlo CPortAudioSoundRecorder.cpp:87: warning: #warning test with some parameters that I know will fail CPortAudioSoundRecorder.cpp: In method `void CPortAudioSoundRecorder::deinitialize()': CPortAudioSoundRecorder.cpp:109: `stderr' undeclared (first use this function) CPortAudioSoundRecorder.cpp:109: (Each undeclared identifier is reported only once CPortAudioSoundRecorder.cpp:109: for each function it appears in.) CPortAudioSoundRecorder.cpp:109: implicit declaration of function `int fprintf(...)' make[3]: *** [CPortAudioSoundRecorder.lo] Error 1 make[3]: Leaving directory `/y/src/rezound-0.9.1beta_test/src/backend' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/y/src/rezound-0.9.1beta_test/src/backend' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/y/src/rezound-0.9.1beta_test/src' make: *** [all-recursive] Error 1 Adding #include <cstdio> to this file eliminates the fatal error. After that, the make completed successfully. $ rezound using path '/y/src/rezound-0.9.1beta_test/share' for share data directory Error occurred while initializing audio output method 'oss' -- void COSSSoundPlayer::initialize() -- error opening OSS device '/dev/dsp -- Device or resource busy Given `./configure --prefix=/INSTALL/rezound', the correct path should probably be something like /INSTALL/rezound/share/rezound/. How do I tell it to use JACK and not OSS? The device is presumably busy because JACK is already running. A preliminary test ran for a while playing an MP3 file through JACK and into JAMin. After a minute or so it got zombified by JACK (kicked out of the graph). Running without JAMin (which uses a lot of DSP processing cycles) it runs for much longer with JACK load levels in the 4% to 7% range. IIRC, this is much better than the results I was getting a while back. -- joq |
From: Davy D. <dd...@us...> - 2004-04-11 03:51:09
|
Jack O'Quin wrote: >Adding #include <cstdio> to this file eliminates the fatal error. >After that, the make completed successfully. > > > That's interesting, because I'm including stdio.h.. I wonder what the deal is... > $ rezound >using path '/y/src/rezound-0.9.1beta_test/share' for share data directory >Error occurred while initializing audio output method 'oss' -- void COSSSoundPlayer::initialize() -- error opening OSS device '/dev/dsp -- Device or resource busy > >Given `./configure --prefix=/INSTALL/rezound', the correct path should >probably be something like /INSTALL/rezound/share/rezound/. > >How do I tell it to use JACK and not OSS? The device is presumably >busy because JACK is already running. > > > Edit ~/.rezound/registry.dat and make AudioOutputMethods and AudioInputMethods list 'jack' first, then 'oss'. >A preliminary test ran for a while playing an MP3 file through JACK >and into JAMin. After a minute or so it got zombified by JACK (kicked >out of the graph). Running without JAMin (which uses a lot of DSP >processing cycles) it runs for much longer with JACK load levels in >the 4% to 7% range. IIRC, this is much better than the results I was >getting a while back. > > Well, at this point, all bets are off for JACK.. I've not tested it using JACK yet nor have I attempted to make sure it's correctly following JACK's rules... as I said, this is just a large step in that direction, but I'm not there yet. |
From: Jack O'Q. <jo...@io...> - 2004-04-11 04:09:59
|
Davy Durham <dd...@us...> writes: > Well, at this point, all bets are off for JACK.. I've not tested it > using JACK yet nor have I attempted to make sure it's correctly > following JACK's rules... as I said, this is just a large step in that > direction, but I'm not there yet. Seems like a big improvement. I'm not trying to stress it at low latencies, but it does basically work. Seems like progress to me. -- joq |
From: CyberPunk X C. <cyb...@ea...> - 2004-04-11 04:37:33
|
I don't know if I'm following this or not. Does this mean that ReZound doesn't work on Debian? I'm planning to switch to Debian in July after their new stable release is out. I really don't want to lose ReZound, there's nothing like it out there. Kate Draven Jack O'Quin wrote: >Davy Durham <dd...@us...> writes: > > > >>Well, at this point, all bets are off for JACK.. I've not tested it >>using JACK yet nor have I attempted to make sure it's correctly >>following JACK's rules... as I said, this is just a large step in that >>direction, but I'm not there yet. >> >> > >Seems like a big improvement. I'm not trying to stress it at low >latencies, but it does basically work. Seems like progress to me. > > |
From: Jack O'Q. <jo...@io...> - 2004-04-11 05:19:52
|
CyberPunk X Computers <cyb...@ea...> writes: > I don't know if I'm following this or not. > Does this mean that ReZound doesn't work on Debian? > I'm planning to switch to Debian in July after their new stable > release is out. Not at all. We're just testing a new experimental version. With it, the JACK support is better than before, but not yet completely solid. Rezound works fine on Debian. I only mentioned Debian woody in an earlier message to explain why I'm still using the 2.95.4 compiler, because that's what my C++ libraries were compiled with. The C++ ABI changed with the 3.2 compiler (used in Sarge). For C++ it's important to use the compiler that matches your libraries. This ABI problem is not unique to Debian. Have fun with Debian, it's a great system. -- joq |
From: CyberPunk X C. <cyb...@ea...> - 2004-04-11 09:15:45
|
Thank you Jack lol for a second there I thought OH NO! I'm currently using Redhat 9, which is ok. I was going to switch to Fedora but after throughly testing Core 1, I changed my mind. When I read how Debian is dedicated to stable releases and how it followed precise guild line. I became very interested. I don't mind play about with unstable stuff but on the machines I make my living with. I also appreciate their honesty. Thank you for answering, Kate Draven Jack O'Quin wrote: >CyberPunk X Computers <cyb...@ea...> writes: > > > >>I don't know if I'm following this or not. >>Does this mean that ReZound doesn't work on Debian? >>I'm planning to switch to Debian in July after their new stable >>release is out. >> >> > >Not at all. We're just testing a new experimental version. With it, >the JACK support is better than before, but not yet completely solid. > >Rezound works fine on Debian. > >I only mentioned Debian woody in an earlier message to explain why I'm >still using the 2.95.4 compiler, because that's what my C++ libraries >were compiled with. The C++ ABI changed with the 3.2 compiler (used >in Sarge). For C++ it's important to use the compiler that matches >your libraries. This ABI problem is not unique to Debian. > >Have fun with Debian, it's a great system. > > |
From: Rui N. C. <rn...@rn...> - 2004-04-10 21:24:44
Attachments:
rezound-0.9.1beta_test1.png
|
Hi, I've checked out rezound-0.9.1beta_test today, from joq's site as suggested, and built it successfully on my SUSE 9.0 box (also with fox-1.0.49, built from source). You may remember me of my dreaded old problem using rezound-0.9.0beta on this system (see bug #847233 "Sound file load freezes at 99%"). This bug is haunting me for quite a while and I though this test release could put things a little bit further. But no. It simply refuses to load any simple soundfile out there. But this time it spits out an error message box, though cryptic for my eyes. A screeshot of it is appended to this note. When I close that message box, it shows another about 'void CMutex::lock() -- error aquiring lock -- Invalid argument'. This is somewhat a disparate behaviour from the '99% load freeze', so I'm reporting this in a hope it may shed some light out there. Nevertheless ReZound remains completely unusable on my preferred linux box. Has anybody out there built and run rezound for SUSE 9.0 ? I'm asking this because I think I'm not the only one regarding this showstopper. I truely love rezound. It's a killer. I just don't want to be the victim :) Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... Davy Durham wrote: > >>Just realized that it is probably not worthwhile for either of us to >>spend much time getting rezound CVS running on my system. >> >>Probably simpler for you to build a `make dist' tarball of the new >>output code for me (and others) to test with. >> >> > Alright, Jack has offered the use of his server.. Here's a link to the > latest CVS with the audio output patch applied... > > http://www.joq.us/rezound/rezound-0.9.1beta_test.tar.gz > |
From: Davy D. <dd...@ne...> - 2004-04-10 21:57:47
|
Rui Nuno Capela wrote: >Hi, > >I've checked out rezound-0.9.1beta_test today, from joq's site as >suggested, and built it successfully on my SUSE 9.0 box (also with >fox-1.0.49, built from source). > >You may remember me of my dreaded old problem using rezound-0.9.0beta on >this system (see bug #847233 "Sound file load freezes at 99%"). This bug >is haunting me for quite a while and I though this test release could put >things a little bit further. > >But no. It simply refuses to load any simple soundfile out there. But this >time it spits out an error message box, though cryptic for my eyes. A >screeshot of it is appended to this note. > > Do you get this error when loading a .wav or .rez or something else? Does every file (regardless of the format type) do this? |
From: Rui N. C. <rn...@rn...> - 2004-04-10 22:31:57
|
Hi David, >> >>I've checked out rezound-0.9.1beta_test today, from joq's site as >>suggested, and built it successfully on my SUSE 9.0 box (also with >>fox-1.0.49, built from source). >> >>You may remember me of my dreaded old problem using rezound-0.9.0beta on >>this system (see bug #847233 "Sound file load freezes at 99%"). This bug >>is haunting me for quite a while and I though this test release could >> put things a little bit further. >> >>But no. It simply refuses to load any simple soundfile out there. But >> this time it spits out an error message box, though cryptic for my >> eyes. A screeshot of it is appended to this note. >> >> > Do you get this error when loading a .wav or .rez or something else? > Does every file (regardless of the format type) do this? > I get that on loading .wav and .ogg files. The only ones I try to. The result is the same on every one and each file I try to open. The loading progress bar goes far until after 99% and then, BANG! Oh, and after I close the error message box, rezound bails out. Puff! Here is what I have installed, as sorted dependencias for rezound: audiofile-0.2.3 fftw-2.1.3 flac-1.1.0 fox-1.0.49 jack-0.96.2 libjpeg-6.2.0 libogg-1.1 libpng-1.2.5 libstdc++-3.3.1 libtiff-3.5.7 libvorbis-1.0 XFree86-Mesa-4.3.0.1 Bye, -- rncbc aka Rui Nuno Capela rn...@rn... |
From: Rui N. C. <rn...@rn...> - 2004-04-10 22:32:33
|
Hi David, >> >>I've checked out rezound-0.9.1beta_test today, from joq's site as >>suggested, and built it successfully on my SUSE 9.0 box (also with >>fox-1.0.49, built from source). >> >>You may remember me of my dreaded old problem using rezound-0.9.0beta on >>this system (see bug #847233 "Sound file load freezes at 99%"). This bug >>is haunting me for quite a while and I though this test release could >> put things a little bit further. >> >>But no. It simply refuses to load any simple soundfile out there. But >> this time it spits out an error message box, though cryptic for my >> eyes. A screeshot of it is appended to this note. >> >> > Do you get this error when loading a .wav or .rez or something else? > Does every file (regardless of the format type) do this? > I get that on loading .wav and .ogg files. The only ones I try to. The result is the same on every one and each file I try to open. The loading progress bar goes far until after 99% and then, BANG! Oh, and after I close the error message box, rezound bails out. Puff! Here is what I have installed, as sorted dependencias for rezound: audiofile-0.2.3 fftw-2.1.3 flac-1.1.0 fox-1.0.49 jack-0.96.2 libjpeg-6.2.0 libogg-1.1 libpng-1.2.5 libstdc++-3.3.1 libtiff-3.5.7 libvorbis-1.0 XFree86-Mesa-4.3.0.1 Bye, -- rncbc aka Rui Nuno Capela rn...@rn... |
From: Rui N. C. <rn...@rn...> - 2004-04-11 11:04:46
|
Davy, Thanks for your interest. >> > Well, It may be a while before I can, but I'll try to install SuSE 9 on > a box and see what the deal is. > As before, while on the "99% freeze bug", do you think taking a gdb session and doing a backtrack trace would help? Remember that the behaviour was sligthly different whether I was running a SMP kernel or not, but the end result is the same. No file loading. There were some other users reporting the same issue, althought on UP. Guess that SUSE 9 has some hidden troll in there... :/ OTOH I'll upgrade to SUSE 9.1 as soon as it comes out (May 6+). I hope things get better then... :) Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... |
From: Rui N. C. <rn...@rn...> - 2004-04-11 11:47:40
|
Hi Davy, > > As before, while on the "99% freeze bug", do you think taking a gdb > session and doing a backtrack trace would help? > I took the gdb session and it's here: -------------------------------------------------------------- rncbc@gamma-suse1:~/src/rezound/rezound-0.9.1beta_test> gdb ./rezound GNU gdb 5.3.92 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-suse-linux"... (gdb) run Starting program: /home/rncbc/src/rezound/rezound-0.9.1beta_test/rezound [New Thread 16384 (LWP 25496)] using path '/home/rncbc/src/rezound/rezound-0.9.1beta_test/share' for share data directory [New Thread 32769 (LWP 25522)] [New Thread 16386 (LWP 25523)] Detaching after fork from child process 25524. warning: didn't write whole buffer -- only wrote 996 of 8192 bytes Detaching after fork from child process 25526. warning: didn't write whole buffer -- only wrote 1196 of 8192 bytes Detaching after fork from child process 25528. warning: didn't write whole buffer -- only wrote 3704 of 8192 bytes warning: didn't write whole buffer -- only wrote 1548 of 8192 bytes warning: didn't write whole buffer -- only wrote 3196 of 8192 bytes warning: didn't write whole buffer -- only wrote 2724 of 8192 bytes warning: didn't write whole buffer -- only wrote 3736 of 8192 bytes warning: didn't write whole buffer -- only wrote 36 of 8192 bytes warning: didn't write whole buffer -- only wrote 3880 of 8192 bytes warning: didn't write whole buffer -- only wrote 40 of 8192 bytes warning: didn't write whole buffer -- only wrote 4056 of 8192 bytes warning: didn't write whole buffer -- only wrote 600 of 8192 bytes warning: didn't write whole buffer -- only wrote 368 of 8192 bytes warning: didn't write whole buffer -- only wrote 844 of 8192 bytes warning: didn't write whole buffer -- only wrote 2400 of 8192 bytes warning: didn't write whole buffer -- only wrote 2872 of 8192 bytes warning: didn't write whole buffer -- only wrote 464 of 8192 bytes warning: didn't write whole buffer -- only wrote 2768 of 8192 bytes warning: didn't write whole buffer -- only wrote 2968 of 8192 bytes warning: didn't write whole buffer -- only wrote 1904 of 8192 bytes warning: didn't write whole buffer -- only wrote 2108 of 8192 bytes warning: didn't write whole buffer -- only wrote 4040 of 8192 bytes warning: didn't write whole buffer -- only wrote 1564 of 8192 bytes error - void TPoolFile<_l_addr_t, _p_addr_t>::cacheBlock(l_addr_t, const TStaticPoolAccesser<pool_element_t, TPoolFile<_l_addr_t, _p_addr_t> >*) [with pool_element_t = int16_t, _l_addr_t = sample_pos_t, _p_addr_t = uint64_t] -- invalid peWhere 4 for pool (poolId: 9 name: '__GENERAL__ OutputRoutes_v2' byte size: 8 byte alignment: 2) exception caught in play thread: bool CMutex::trylock() -- error doing try lock -- Invalid argument Program received signal SIGINT, Interrupt. [Switching to Thread 16384 (LWP 25496)] 0x40976851 in select () from /lib/i686/libc.so.6 (gdb) info threads 2 Thread 32769 (LWP 25522) 0x40974b66 in poll () from /lib/i686/libc.so.6 * 1 Thread 16384 (LWP 25496) 0x40976851 in select () from /lib/i686/libc.so.6 (gdb) thread 2 [Switching to thread 2 (Thread 32769 (LWP 25522))]#0 0x40974b66 in poll () from /lib/i686/libc.so.6 (gdb) bt #0 0x40974b66 in poll () from /lib/i686/libc.so.6 #1 0x40039a8e in __pthread_manager () from /lib/i686/libpthread.so.0 #2 0x40039d63 in __pthread_manager_event () from /lib/i686/libpthread.so.0 #3 0x4097d327 in clone () from /lib/i686/libc.so.6 (gdb) thread 1 [Switching to thread 1 (Thread 16384 (LWP 25496))]#0 0x40976851 in select () from /lib/i686/libc.so.6 (gdb) bt #0 0x40976851 in select () from /lib/i686/libc.so.6 #1 0x4057b994 in ?? () from /usr/local/lib/libFOX-1.0.so.0 #2 0x00000001 in ?? () #3 0xffffffd8 in ?? () #4 0x4038851b in FXApp::getNextEvent(_XEvent&, unsigned char) () from /usr/local/lib/libFOX-1.0.so.0 (gdb) quit The program is running. Exit anyway? (y or n) y rncbc@gamma-suse1:~/src/rezound/rezound-0.9.1beta_test> -------------------------------------------------------------- My system is: Linux gamma-suse1 2.6.5-0smp #1 SMP Mon Apr 5 21:50:59 WEST 2004 i686 i686 i386 GNU/Linux CPU: P4 2.80C@3.3Ghz HT RAM: 1GB DDR400 Mobo: ASUS P4P800 Deluxe-EAY Distro: SUSE 9.0 Desktop: KDE 3.2.1 rncbc@gamma-suse1:~/src/rezound/rezound-0.9.1beta_test> ldd ./rezound | awk '{print $3}' | xargs rpm -qf | sort | uniq audiofile-0.2.3-338 fftw-2.1.3-921 flac-1.1.0-201 fox-1.0.49-1 glibc-2.3.2-88 jack-0.96.2-1 libgcc-3.3.1-24 libjpeg-6.2.0-630 libogg-1.1-0.pm.0 libpng-1.2.5-93 libstdc++-3.3.1-24 libtiff-3.5.7-302 libvorbis-1.0-195 XFree86-libs-4.3.0.1-21 XFree86-Mesa-4.3.0.1-21 zlib-1.1.4-225 And now what? Just tell me what to do next. Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... |
From: Jack O'Q. <jo...@io...> - 2004-04-11 15:06:42
|
"Rui Nuno Capela" <rn...@rn...> writes: > rncbc@gamma-suse1:~/src/rezound/rezound-0.9.1beta_test> ldd ./rezound | > awk '{print $3}' | xargs rpm -qf | sort | uniq > audiofile-0.2.3-338 > fftw-2.1.3-921 > flac-1.1.0-201 > fox-1.0.49-1 I had to download an build libfox-1.1 from sources to build the latest rezound. How were you able to configure it with libfox-1.0? -- joq |
From: Rui N. C. <rn...@rn...> - 2004-04-11 15:30:38
|
Hi Jack, > >> rncbc@gamma-suse1:~/src/rezound/rezound-0.9.1beta_test> ldd ./rezound | >> awk '{print $3}' | xargs rpm -qf | sort | uniq >> audiofile-0.2.3-338 >> fftw-2.1.3-921 >> flac-1.1.0-201 >> fox-1.0.49-1 > > I had to download and build libfox-1.1 from sources to build the latest > rezound. How were you able to configure it with libfox-1.0? > I have tried before either with libfox-1.1 and with libfox-1.0. I don't quite remember very well what was the hacks I had to do to build rezound correctly for libfox-1.1. IIRC, with libfox-1.1, I had to create a symlink, something like /usr/local/include/fox -> /usr/local/include/fox-1.1, and also had to edit the rezound source to stuff in some suspicious C++ type casts. Besides that, rezound builds with either fox version. I think all is taken care on configure time. OTOH, I always use checkinstall to build and install a rpm for me, instead of just `make install`. That's the reference for fox-1.0.49-1 above. All my build from source are set from ./configure --prefix=/usr/local ... But back to my old problem, I come to the conclusion before that it's not related to libfox version. On either one, it bangs. But I will try with newest libfox-1.1 once again, so stay tuned... :) BBL -- rncbc aka Rui Nuno Capela rn...@rn... |
From: Rui N. C. <rn...@rn...> - 2004-05-24 20:54:20
|
Hi, Remember my 99% freeze problem on loading any audiofile on SUSE 9.0 (bug #847233, see below) ? I've upgraded to SUSE 9.1 last week and rebuilt rezound-0.9.1beta_test, and it doesn't suffer of this crippling illness anymore. HURRAY! For the record, the main relevant packages in use are the following: fox-1.2.1 jack-0.98.1 gcc-3.3.3 glibc-2.3.3 I'm happy now :) Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... > > I've checked out rezound-0.9.1beta_test today, from joq's site as > suggested, and built it successfully on my SUSE 9.0 box (also with > fox-1.0.49, built from source). > > You may remember me of my dreaded old problem using rezound-0.9.0beta on > this system (see bug #847233 "Sound file load freezes at 99%"). This bug > is haunting me for quite a while and I though this test release could > put things a little bit further. > > But no. It simply refuses to load any simple soundfile out there. > But this time it spits out an error message box, though cryptic for > my eyes. A > screeshot of it is appended to this note. > > When I close that message box, it shows another about > 'void CMutex::lock() -- error aquiring lock -- Invalid argument'. > > This is somewhat a disparate behaviour from the '99% load freeze', > so I'm reporting this in a hope it may shed some light out there. > Nevertheless ReZound remains completely unusable on my preferred > linux box. > > Has anybody out there built and run rezound for SUSE 9.0 ? I'm > asking this because I think I'm not the only one regarding this > showstopper. > > I truely love rezound. It's a killer. I just don't want to be > the victim :) > > Davy Durham wrote: >> >>>Just realized that it is probably not worthwhile for either of us to >>>spend much time getting rezound CVS running on my system. >>> >>>Probably simpler for you to build a `make dist' tarball of the new >>>output code for me (and others) to test with. >>> >>> >> Alright, Jack has offered the use of his server.. Here's a link to the >> latest CVS with the audio output patch applied... >> >> http://www.joq.us/rezound/rezound-0.9.1beta_test.tar.gz >> > > |