On Mon, Oct 25, 2004 at 06:31:32AM -0400, Ge Wang wrote: screenshot looks great so i had to try it! but on a Mandrake9.2 and a Gentoo machine (both X 4.3.0, ati r200), i get a segfault: [tim@sofa sndpeek]$ gdb ./sndpeek GNU gdb 5.3-25mdk (Mandrake Linux) Copyright 2002 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-mandrake-linux-gnu"... (gdb) run Starting program: /home/tim/sndpeek-1.0/src/sndpeek/sndpeek Loading required GL library /usr/X11R6/lib/libGL.so.1.2 libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) drmOpenByBusid: busid is PCI:1:0:0 drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenByBusid: drmOpenMinor returns 6 drmOpenByBusid: drmGetBusid reports PCI:1:0:0 Program received signal SIGFPE, Arithmetic exception. 0x40779d33 in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so (gdb) backtrace #0 0x40779d33 in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so #1 0x40779a81 in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so #2 0x40779bed in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so #3 0x406ecc8b in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so #4 0x4066ffba in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so #5 0x40672147 in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so #6 0x406725b7 in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so #7 0x4077e259 in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so #8 0x4065d84c in __driUtilUpdateDrawableInfo () from /usr/X11R6/lib/modules/dri/r200_dri.so #9 0x40607a06 in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1.2 #10 0x40607a7e in glXCreateContext () from /usr/X11R6/lib/libGL.so.1.2 (gdb) hope you find this info useful. cheers -- Tim Orford

On Tue, 2004-10-26 at 13:48, Kevin Ernste wrote: > It runs here fine with ALSA (looks great, by the way, thanks for the > nice work!). However, the JACK version locks up the terminal and the > process cannot be killed. in fact "ps" dies even trying to view the > PID, etc. I would be happy to try and better diagnose it if others > have a similar problem.

Thanks Dan. No joy after setting LD_ASSUME_KERNEL, same behavior. Hopefully some of the bugs will get ironed out (here or with sndpeek), it looks promising indeed. Kevin On Tue, 26 Oct 2004 23:00:56 +0100, Dan Mills <dmills(a)spamblock.demon.co.uk> wrote: > On Tuesday 26 October 2004 22:17, Fernando Pablo Lopez-Lezcano wrote: >> On Tue, 2004-10-26 at 13:48, Kevin Ernste wrote: >>> It runs here fine with ALSA (looks great, by the way, thanks for the >>> nice work!). However, the JACK version locks up the terminal and >>> the >>> process cannot be killed. in fact "ps" dies even trying to view the >>> PID, etc. I would be happy to try and better diagnose it if others >>> have a similar problem. > > The jack version is OK here (recent CVS jack), radeon 9200 graphics, > fun > program. > > Now if I just knew enough open GL to add calibration scales for the > frequency > response graph life would be good! > > The ps dying thing is reminiscent of the problems qjackctl used to > have with > the NPTL threading library on kernel 2.6, possibly try the > LD_ASSUME_KERNEL > workaround? > > Regards, Dan. >

Sorry for the multiple post: For those systems that are crashing somewhere in the display driver (according to gdb), try the following: set LIBGL_ALWAYS_INDIRECT environment variable to 1 this disables hardware rendering. if it works: - the problem is likely with the display driver - it will be very slow if it doesn't: - there is a different bug in sndpeek we need to fix Best, Ge! On Oct 27, 2004, at 6:19 PM, Ge Wang wrote: > Thanks to all who have downloaded and sndpeek'd - > and for the great suggestions, most of which we will > put into the next version. > > regarding sndpeek crashing using JACK: > > We are trying to track this down. So far ALSA seems fine - > please let us know if sndpeek crashes with ALSA on your > system. There seems to be some issues with opening audio > input using JACK with RtAudio on certain systems. When > this fails, there should be an exception thrown, but we found > that this is disabled in the current build. It is a possible source > of the crash. Stack traces suggest sndpeek crashes deep in > the glutCreateWindow(). Perhaps updating the video driver > may fix this problem. We hope to have a more robust fix soon! > > Best, > Ge! > > On Oct 26, 2004, at 10:51 PM, Kevin Ernste wrote: > >> Thanks Dan. No joy after setting LD_ASSUME_KERNEL, same behavior. >> Hopefully some of the bugs will get ironed out (here or with sndpeek), >> it looks promising indeed. >> >> Kevin >> >> On Tue, 26 Oct 2004 23:00:56 +0100, Dan Mills >> <dmills(a)spamblock.demon.co.uk> wrote: >>> On Tuesday 26 October 2004 22:17, Fernando Pablo Lopez-Lezcano wrote: >>>> On Tue, 2004-10-26 at 13:48, Kevin Ernste wrote: >>>>> It runs here fine with ALSA (looks great, by the way, thanks for >>>>> the >>>>> nice work!). However, the JACK version locks up the terminal >>>>> and the >>>>> process cannot be killed. in fact "ps" dies even trying to view the >>>>> PID, etc. I would be happy to try and better diagnose it if others >>>>> have a similar problem. >>> >>> The jack version is OK here (recent CVS jack), radeon 9200 >>> graphics, fun >>> program. >>> >>> Now if I just knew enough open GL to add calibration scales for >>> the frequency >>> response graph life would be good! >>> >>> The ps dying thing is reminiscent of the problems qjackctl used to >>> have with >>> the NPTL threading library on kernel 2.6, possibly try the >>> LD_ASSUME_KERNEL >>> workaround? >>> >>> Regards, Dan. >>>

Greetings Michal and all, It seems that we really need to beef up our JACK support. ChucK, sndpeek, and rt_lpc all use RtAudio to interface with JACK, and we can figure out how to make that run (much) better, then all three would totally benefit. Thanks for the feedback. We will make this a priority. If anyone here would like to help with this endeavor, please let us know! Thank you once again! Best, Ge! On Oct 27, 2004, at 10:06 PM, Michal Seta wrote: > I haven't tried andpeek but rt_lpc crashes for me with the same > symptoms. I discovered that it does crash in the glut somehere (as > you mentioned in your previous message) but exporting the env variable > below makes it crash anyways with the RtApiJack as so: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 16384 (LWP 20832)] > 0x08051605 in RtApiJack::startStream() () > (gdb) where > #0 0x08051605 in RtApiJack::startStream() () > #1 0x0804c3b4 in initialize_audio() () > #2 0x0804bfee in main () > > Also, chuck is crashing on me frequently. It does happen when I > switch virtual screens and with various screen updates (like opening > the fluxbox menu). > > Chuck prints the following message: > RtApiJack: the Jack server is shutting down ... stream stopped and > closed!!! > > but Jack is not shutting down. Jack runs happily ever after. > > I should mention, however, that I have the unichrome video chip which > seems is not yet perfectly supported (and perhaps it's not really a > good choice for rendering chip anyways). > > rt_lpc runs fine with alsa, though (with direct rendering, in fact) > but I haven't tried chuck with alsa yet. To tell the truth I have > little interest in running it without jack, if that matters at all. > > cheers, > > ./MiS > > Ge Wang <gewang(a)cs.princeton.edu> writes: > >> Sorry for the multiple post: >> >> For those systems that are crashing somewhere in the >> display driver (according to gdb), try the following: >> >> set LIBGL_ALWAYS_INDIRECT environment variable to 1 >> >> this disables hardware rendering. >> >> if it works: >> - the problem is likely with the display driver >> - it will be very slow >> >> if it doesn't: >> - there is a different bug in sndpeek we need to fix >> >> Best, >> Ge! >> >> >> On Oct 27, 2004, at 6:19 PM, Ge Wang wrote: >> >>> Thanks to all who have downloaded and sndpeek'd - >>> and for the great suggestions, most of which we will >>> put into the next version. >>> >>> regarding sndpeek crashing using JACK: >>> >>> We are trying to track this down. So far ALSA seems fine - >>> please let us know if sndpeek crashes with ALSA on your >>> system. There seems to be some issues with opening audio >>> input using JACK with RtAudio on certain systems. When >>> this fails, there should be an exception thrown, but we found >>> that this is disabled in the current build. It is a possible source >>> of the crash. Stack traces suggest sndpeek crashes deep in >>> the glutCreateWindow(). Perhaps updating the video driver >>> may fix this problem. We hope to have a more robust fix soon! >>> >>> Best, >>> Ge! >>> >>> On Oct 26, 2004, at 10:51 PM, Kevin Ernste wrote: >>> >>>> Thanks Dan. No joy after setting LD_ASSUME_KERNEL, same behavior. >>>> Hopefully some of the bugs will get ironed out (here or with >>>> sndpeek), >>>> it looks promising indeed. >>>> >>>> Kevin >>>> >>>> On Tue, 26 Oct 2004 23:00:56 +0100, Dan Mills >>>> <dmills(a)spamblock.demon.co.uk> wrote: >>>>> On Tuesday 26 October 2004 22:17, Fernando Pablo Lopez-Lezcano >>>>> wrote: >>>>>> On Tue, 2004-10-26 at 13:48, Kevin Ernste wrote: >>>>>>> It runs here fine with ALSA (looks great, by the way, thanks for >>>>>>> the >>>>>>> nice work!). However, the JACK version locks up the terminal >>>>>>> and the >>>>>>> process cannot be killed. in fact "ps" dies even trying to >>>>>>> view the >>>>>>> PID, etc. I would be happy to try and better diagnose it if >>>>>>> others >>>>>>> have a similar problem. >>>>> >>>>> The jack version is OK here (recent CVS jack), radeon 9200 >>>>> graphics, fun >>>>> program. >>>>> >>>>> Now if I just knew enough open GL to add calibration scales for >>>>> the frequency >>>>> response graph life would be good! >>>>> >>>>> The ps dying thing is reminiscent of the problems qjackctl used to >>>>> have with >>>>> the NPTL threading library on kernel 2.6, possibly try the >>>>> LD_ASSUME_KERNEL >>>>> workaround? >>>>> >>>>> Regards, Dan. >>>>>