After a few more tests... after having disabled my dri chuck runs fine with jack. I did not try for very extended periods of time but it lasted at least 15 minutes (before it would die on anything and in very short time) So it is dri that interfers (at least in my case) with apps connecting to the jack graph. I noticed that with qsynth, too. qsynth and chuck would loose connection to jack most often at gfx intense operations (such as switching virtual desktops). That said, I'm probably a special case. I don't have a separate video card and the via chipset shares the RAM with the rest of the system. I had a hard time installing the drivers and when I did succeed, it's been rather fragile, anyways. ./MiS Ge Wang <gewang@xxxxxxxxxxxxxxxx> writes: > 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> 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. > >>>>>
