From: Allan K. <al...@do...> - 2005-04-03 04:18:27
|
Hi All I've just installed version 0.7.1 and I get the following error. open projectfile: No such file or directory starting with default template WatchDog: fatal error, realtime task timeout (0,0-3) - stopping all services I also get this message on compiling checking for libfst... Package libfst was not found in the pkg-config search path. Perhaps you should add the directory containing `libfst.pc' to the PKG_CONFIG_PATH environment variable No package 'libfst' found I've tried using both the Gentoo ebuild and manually compiling it myself. I'm on an athlon 3500+ using Gentoo with a 2.6.9 kernel. Any ideas? cheers -- Allan Klinbail <al...@do...> |
From: Joachim S. <js...@du...> - 2005-04-03 10:52:21
|
On Sunday 03 April 2005 06:25, Allan Klinbail wrote: > Hi All > > I've just installed version 0.7.1 and I get the following error. > > open projectfile: No such file or directory > starting with default template > WatchDog: fatal error, realtime task timeout > (0,0-3) - stopping all services That seems bad - not having realtime can result in a very bad timing. http://www.muse-sequencer.org/wiki/index.php/Realtime-lsm_module In most cases you don't have to recompile the kernel - just be sure everything is checked and you compile the realtime.ko module ;-) Good luck > I also get this message on compiling > > checking for libfst... Package libfst was not found in the pkg-config > search path. > Perhaps you should add the directory containing `libfst.pc' > to the PKG_CONFIG_PATH environment variable > No package 'libfst' found You should not need libfst in the first place. Libfst is for support of VstI (not VST plugins) so you can use several synthesizers with MusE. If you want that install the lib, recompile and you're done. > I've tried using both the Gentoo ebuild and manually compiling it > myself. I'm on an athlon 3500+ using Gentoo with a 2.6.9 kernel. Any > ideas? > > cheers Q |
From: Allan K. <al...@do...> - 2005-04-05 11:22:15
|
Hi I have a realtime compiled kernel, as the jack server works very well with other software. Simply I get this shutdown error with MusE alone. cheers Allan On Sun, 2005-04-03 at 12:52 +0200, Joachim Schiele wrote: > On Sunday 03 April 2005 06:25, Allan Klinbail wrote: > > Hi All > > > > I've just installed version 0.7.1 and I get the following error. > > > > open projectfile: No such file or directory > > starting with default template > > WatchDog: fatal error, realtime task timeout > > (0,0-3) - stopping all services > > That seems bad - not having realtime can result in a very bad timing. > http://www.muse-sequencer.org/wiki/index.php/Realtime-lsm_module > > In most cases you don't have to recompile the kernel - just be sure everything > is checked and you compile the realtime.ko module ;-) > > Good luck > > > I also get this message on compiling > > > > checking for libfst... Package libfst was not found in the pkg-config > > search path. > > Perhaps you should add the directory containing `libfst.pc' > > to the PKG_CONFIG_PATH environment variable > > No package 'libfst' found > You should not need libfst in the first place. Libfst is for support of VstI > (not VST plugins) so you can use several synthesizers with MusE. > > If you want that install the lib, recompile and you're done. > > > I've tried using both the Gentoo ebuild and manually compiling it > > myself. I'm on an athlon 3500+ using Gentoo with a 2.6.9 kernel. Any > > ideas? > > > > cheers > Q > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user > -- Allan Klinbail <al...@do...> |
From: Joachim S. <js...@du...> - 2005-04-05 11:31:07
|
On Tuesday 05 April 2005 13:29, Allan Klinbail wrote: Hey Allan, does "jackstart" work? Or do you get something like this: joachim@knabber:~$ jackstart jackstart: cannot get realtime capabilities, current capabilities are: =3Dep cap_setpcap-e probably running under a kernel with capabilities disabled, a suitable kernel would have printed something like "=3Deip" If you get the line above it's probably a realtime problem, try with realti= me=20 module loaded & root just to be safe. Can you also poste the output of: ./configure, should be something like thi= s: configure: MusE configured using rtcap: no LADCCA support: no setuid root install: no setuid root build: no fluidsynth softsynth: yes VST/win support: no jade: jade doxygen: /usr/bin/doxygen graphviz: no perl: /usr/bin/perl treeviews in doxygen html output: yes C++ compiler: g++ optimizing: no debug: no optimise for arch: none installation prefix: /usr/local Also the version of: libqt3-mt-dev 3.2.3-2 Qt development files (Threaded) automake1.9 1.9.3-1 A tool for generating GNU Standards-complian libjack0.80.0-0 0.98.1-4 JACK Audio Connection Kit (libraries)=20 libjack0.80.0-dev 0.98.1-4 JACK Audio Connection Kit (development files) libsndfile1 1.0.10-2 Library for reading/writing audio files=20 libsndfile1-dev 1.0.10-2 Library for reading/writing audio files Joachim Schiele Werner: Do you have idea here what could be going wrong? > Hi > > I have a realtime compiled kernel, as the jack server works very well > with other software. Simply I get this shutdown error with MusE alone. > cheers > > Allan > > On Sun, 2005-04-03 at 12:52 +0200, Joachim Schiele wrote: > > On Sunday 03 April 2005 06:25, Allan Klinbail wrote: > > > Hi All > > > > > > I've just installed version 0.7.1 and I get the following error. > > > > > > open projectfile: No such file or directory > > > starting with default template > > > WatchDog: fatal error, realtime task timeout > > > (0,0-3) - stopping all services > > > > That seems bad - not having realtime can result in a very bad timing. > > http://www.muse-sequencer.org/wiki/index.php/Realtime-lsm_module > > > > In most cases you don't have to recompile the kernel - just be sure > > everything is checked and you compile the realtime.ko module ;-) > > > > Good luck > > > > > I also get this message on compiling > > > > > > checking for libfst... Package libfst was not found in the pkg-config > > > search path. > > > Perhaps you should add the directory containing `libfst.pc' > > > to the PKG_CONFIG_PATH environment variable > > > No package 'libfst' found > > > > You should not need libfst in the first place. Libfst is for support of > > VstI (not VST plugins) so you can use several synthesizers with MusE. > > > > If you want that install the lib, recompile and you're done. > > > > > I've tried using both the Gentoo ebuild and manually compiling it > > > myself. I'm on an athlon 3500+ using Gentoo with a 2.6.9 kernel. Any > > > ideas? > > > > > > cheers > > > > Q > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick > > _______________________________________________ > > Lmuse-user mailing list > > Lmu...@li... > > https://lists.sourceforge.net/lists/listinfo/lmuse-user |
From: Robert J. <rj...@sp...> - 2005-04-05 19:59:20
|
Hi, On Tuesday 05 Apr 2005 13:31, Joachim Schiele wrote: > On Tuesday 05 April 2005 13:29, Allan Klinbail wrote: > Hey Allan, > does "jackstart" work? Or do you get something like this: > joachim@knabber:~$ jackstart > jackstart: cannot get realtime capabilities, current capabilities are: > =ep cap_setpcap-e > probably running under a kernel with capabilities disabled, > a suitable kernel would have printed something like "=eip" > > If you get the line above it's probably a realtime problem, try with > realtime module loaded & root just to be safe. Trying as root would be good. I have actually spent a fair amount of time trying to help people getting various configurations of muse and gentoo working... some work some don't... I still don't know why but the combo has an over average number of reported problems. Regards, Robert > > Can you also poste the output of: ./configure, should be something like > this: configure: > > MusE configured > > using rtcap: no > LADCCA support: no > setuid root install: no > setuid root build: no > fluidsynth softsynth: yes > VST/win support: no > > jade: jade > doxygen: /usr/bin/doxygen > graphviz: no > perl: /usr/bin/perl > treeviews in doxygen > html output: yes > > C++ compiler: g++ > optimizing: no > debug: no > optimise for arch: none > > installation prefix: /usr/local > > Also the version of: > libqt3-mt-dev 3.2.3-2 Qt development files (Threaded) > automake1.9 1.9.3-1 A tool for generating GNU Standards-complian > libjack0.80.0-0 0.98.1-4 JACK Audio Connection Kit (libraries) > libjack0.80.0-dev 0.98.1-4 JACK Audio Connection Kit (development files) > libsndfile1 1.0.10-2 Library for reading/writing audio files > libsndfile1-dev 1.0.10-2 Library for reading/writing audio files > > Joachim Schiele > > Werner: Do you have idea here what could be going wrong? > > > Hi > > > > I have a realtime compiled kernel, as the jack server works very well > > with other software. Simply I get this shutdown error with MusE alone. > > cheers > > > > Allan > > > > On Sun, 2005-04-03 at 12:52 +0200, Joachim Schiele wrote: > > > On Sunday 03 April 2005 06:25, Allan Klinbail wrote: > > > > Hi All > > > > > > > > I've just installed version 0.7.1 and I get the following error. > > > > > > > > open projectfile: No such file or directory > > > > starting with default template > > > > WatchDog: fatal error, realtime task timeout > > > > (0,0-3) - stopping all services > > > > > > That seems bad - not having realtime can result in a very bad timing. > > > http://www.muse-sequencer.org/wiki/index.php/Realtime-lsm_module > > > > > > In most cases you don't have to recompile the kernel - just be sure > > > everything is checked and you compile the realtime.ko module ;-) > > > > > > Good luck > > > > > > > I also get this message on compiling > > > > > > > > checking for libfst... Package libfst was not found in the pkg-config > > > > search path. > > > > Perhaps you should add the directory containing `libfst.pc' > > > > to the PKG_CONFIG_PATH environment variable > > > > No package 'libfst' found > > > > > > You should not need libfst in the first place. Libfst is for support of > > > VstI (not VST plugins) so you can use several synthesizers with MusE. > > > > > > If you want that install the lib, recompile and you're done. > > > > > > > I've tried using both the Gentoo ebuild and manually compiling it > > > > myself. I'm on an athlon 3500+ using Gentoo with a 2.6.9 kernel. Any > > > > ideas? > > > > > > > > cheers > > > > > > Q > > > > > > > > > ------------------------------------------------------- > > > SF email is sponsored by - The IT Product Guide > > > Read honest & candid reviews on hundreds of IT Products from real > > > users. Discover which products truly live up to the hype. Start reading > > > now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > _______________________________________________ > > > Lmuse-user mailing list > > > Lmu...@li... > > > https://lists.sourceforge.net/lists/listinfo/lmuse-user -- http://spamatica.se/musicsite/ |
From: Allan K. <al...@do...> - 2005-04-17 11:43:40
|
Hi Sorry to be so late with this answer. I was using jackd in root mode and starting muse as root as well. cheers On Tue, 2005-04-05 at 21:58 +0200, Robert Jonsson wrote: > Hi, > > > On Tuesday 05 Apr 2005 13:31, Joachim Schiele wrote: > > On Tuesday 05 April 2005 13:29, Allan Klinbail wrote: > > Hey Allan, > > does "jackstart" work? Or do you get something like this: > > joachim@knabber:~$ jackstart > > jackstart: cannot get realtime capabilities, current capabilities are: > > =ep cap_setpcap-e > > probably running under a kernel with capabilities disabled, > > a suitable kernel would have printed something like "=eip" > > > > If you get the line above it's probably a realtime problem, try with > > realtime module loaded & root just to be safe. > > Trying as root would be good. I have actually spent a fair amount of time > trying to help people getting various configurations of muse and gentoo > working... some work some don't... I still don't know why but the combo has > an over average number of reported problems. > > Regards, > Robert > > > > > Can you also poste the output of: ./configure, should be something like > > this: configure: > > > > MusE configured > > > > using rtcap: no > > LADCCA support: no > > setuid root install: no > > setuid root build: no > > fluidsynth softsynth: yes > > VST/win support: no > > > > jade: jade > > doxygen: /usr/bin/doxygen > > graphviz: no > > perl: /usr/bin/perl > > treeviews in doxygen > > html output: yes > > > > C++ compiler: g++ > > optimizing: no > > debug: no > > optimise for arch: none > > > > installation prefix: /usr/local > > > > Also the version of: > > libqt3-mt-dev 3.2.3-2 Qt development files (Threaded) > > automake1.9 1.9.3-1 A tool for generating GNU Standards-complian > > libjack0.80.0-0 0.98.1-4 JACK Audio Connection Kit (libraries) > > libjack0.80.0-dev 0.98.1-4 JACK Audio Connection Kit (development files) > > libsndfile1 1.0.10-2 Library for reading/writing audio files > > libsndfile1-dev 1.0.10-2 Library for reading/writing audio files > > > > Joachim Schiele > > > > Werner: Do you have idea here what could be going wrong? > > > > > Hi > > > > > > I have a realtime compiled kernel, as the jack server works very well > > > with other software. Simply I get this shutdown error with MusE alone. > > > cheers > > > > > > Allan > > > > > > On Sun, 2005-04-03 at 12:52 +0200, Joachim Schiele wrote: > > > > On Sunday 03 April 2005 06:25, Allan Klinbail wrote: > > > > > Hi All > > > > > > > > > > I've just installed version 0.7.1 and I get the following error. > > > > > > > > > > open projectfile: No such file or directory > > > > > starting with default template > > > > > WatchDog: fatal error, realtime task timeout > > > > > (0,0-3) - stopping all services > > > > > > > > That seems bad - not having realtime can result in a very bad timing. > > > > http://www.muse-sequencer.org/wiki/index.php/Realtime-lsm_module > > > > > > > > In most cases you don't have to recompile the kernel - just be sure > > > > everything is checked and you compile the realtime.ko module ;-) > > > > > > > > Good luck > > > > > > > > > I also get this message on compiling > > > > > > > > > > checking for libfst... Package libfst was not found in the pkg-config > > > > > search path. > > > > > Perhaps you should add the directory containing `libfst.pc' > > > > > to the PKG_CONFIG_PATH environment variable > > > > > No package 'libfst' found > > > > > > > > You should not need libfst in the first place. Libfst is for support of > > > > VstI (not VST plugins) so you can use several synthesizers with MusE. > > > > > > > > If you want that install the lib, recompile and you're done. > > > > > > > > > I've tried using both the Gentoo ebuild and manually compiling it > > > > > myself. I'm on an athlon 3500+ using Gentoo with a 2.6.9 kernel. Any > > > > > ideas? > > > > > > > > > > cheers > > > > > > > > Q > > > > > > > > > > > > ------------------------------------------------------- > > > > SF email is sponsored by - The IT Product Guide > > > > Read honest & candid reviews on hundreds of IT Products from real > > > > users. Discover which products truly live up to the hype. Start reading > > > > now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > > _______________________________________________ > > > > Lmuse-user mailing list > > > > Lmu...@li... > > > > https://lists.sourceforge.net/lists/listinfo/lmuse-user > -- Allan Klinbail <al...@do...> |
From: Frank H. <fhe...@ya...> - 2005-04-09 21:25:33
|
On Tuesday 05 April 2005 21:58, Robert Jonsson wrote: > Trying as root would be good. I have actually spent a fair amount of time > trying to help people getting various configurations of muse and gentoo > working... some work some don't... I still don't know why but the combo has > an over average number of reported problems. I had the same problem (watchdog: fatal error, realtime task timeout) on my gentoo system as well. Seems like it's a problem with the realtime-lsm module which is in gentoo's portage tree, which reports itself as sys-apps/realtime-lsm-0.8.5-r1. It works well for example with hydrogen, but when I triel to load it with # modprobe realtime allcaps=1 FATAL: Error inserting realtime (/lib/modules/2.6.11-gentoo-r4/extra/realtime.ko): Unknown symbol in module, or unknown parameter (see dmesg) It seems not to know the "allcaps" option. I downloaded realtime-lsm-0.1.1 directly from sourceforge and loaded the new build module with # insmod ./realtime.ko allcaps=1 any=1 and, voila!, muse started. (But seems to be quite unstable and I haven't really tried anything, but that's probably my setup..) Is realtime-0.1.1 from sourceforge neccessary for muse? Could it be the cause of the "over average" problem that gentoo comes with the 0.8.5 version from http://www.joq.us/realtime/ ? |
From: Frank H. <fhe...@ya...> - 2005-04-10 09:27:08
|
Easy win, easy go... muse (0.7.1) was quite unstable and I couldn't load any soundfonts into fluidsynth. So I tried yesterdays CVS version (identifies itself as version 0.8.0pre1). Now I have the watchdog error again, no matter which realtime module I use. I tried gentoo's and hand-compiled versions of the realtime-lsm, jack and muse in different combinations. Yesterday's (semi-)success isn't reproducable. jackstartd -R -d alsa started whithout any problems, hydrogen has no problems to run with these combinations, so I guess it must be something very specific to muses realtime capabilties. Running as root doesn't help either. If I start muse with -d, muse comes up, but offers no audio channes to connect to alsa in qjackctl's connect window. So here's verbose what these sessions typically look like: # su Password: # uname -a Linux MyDesktop 2.6.11-gentoo-r4 #3 Thu Mar 31 22:21:06 CEST 2005 i686 AMD Athlon(tm) XP 1700+ AuthenticAMD GNU/Linux # insmod ./realtime.ko allcaps=1 any=1 (the .1.1 version form sourceforge) # lsmod | grep realtime realtime 10896 0 # exit $ jackstart -R -dalsa -dhw:0 -r48000 -p4096 -n4 back from read, ret = 1 errno == Success jackd 0.99.0 Copyright 2001-2003 Paul Davis and others. jackd comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details loading driver .. apparent rate = 48000 creating alsa driver ... hw:0|hw:0|4096|4|48000|0|0|nomon|swmeter|-|32bit control device hw:0 configuring for 48000Hz, period = 4096 frames, buffer = 4 periods Couldn't open hw:0 for 32bit samples trying 24bit instead Couldn't open hw:0 for 24bit samples trying 16bit instead Couldn't open hw:0 for 32bit samples trying 24bit instead Couldn't open hw:0 for 24bit samples trying 16bit instead $ muse /usr/kde/3.4/bin/konqueror MusE:readConfiguration(): unknown tag drumedit in document #document MusE:readConfiguration(): unknown tag pianoroll in document #document MusE:readConfiguration(): unknown tag masteredit in document #document MusE:readConfiguration(): unknown tag waveedit in document #document MusE:Song: unknown tag automation MusE:Song: unknown tag type MusE: WatchDog: fatal error, realtime task timeout (0,0-3) - stopping all services |
From: Frank H. <fhe...@ya...> - 2005-04-10 10:45:41
|
It's me again ... I hope I do not produce too much noise on the mailing list Now I'm confused. I tried to investigate what's going on. So I put on my working gloves and did go boldly into the source (I'm a lousy programmer!). Obviusly the errormessage comes from these lines in muse/app.cpp bool timeout = false; if (midiSeqRunning && watchMidi == 0) timeout = true; if (watchAudio == 0) timeout = true; if (watchAudio > 500000) timeout = true; if (watchMidi > (config.rtcTicks * WD_TIMEOUT * 2)) timeout = true; if (timeout) ++fatal; else fatal = 0; if (fatal >= 3) { printf("MusE: WatchDog: fatal error, realtime task timeout\n"); printf(" (%d,%d-%d) - stopping all services\n", watchMidi, watchAudio, fatal); break; } So I added some printfs to see which condition caused the timeout. It turned out to be the watchAudio==0 comparison. Being a curious person I simply commented out that if block. And what happened? MusE now works!? Including the softsynths (except for fluidsynth). The timing is quite stable so far, so there seems nothing to be badly broken by that primitive and unqualified hack. Frank Sorry for replying two times to myself, I promise now to wait if there's a reaction at all to my mails ;) ! |
From: Joachim S. <js...@du...> - 2005-04-10 12:45:26
|
On Sunday 10 April 2005 12:45, Frank Hellmuth wrote: > It's me again ... I hope I do not produce too much noise on the mailing > list Hey, This is not a problem because it seems pretty dead sometimes. > Now I'm confused. I tried to investigate what's going on. So I put on my > working gloves and did go boldly into the source (I'm a lousy programmer!). > > Obviusly the errormessage comes from these lines in muse/app.cpp > > bool timeout = false; > if (midiSeqRunning && watchMidi == 0) > timeout = true; > if (watchAudio == 0) > timeout = true; > if (watchAudio > 500000) > timeout = true; > if (watchMidi > (config.rtcTicks * WD_TIMEOUT * 2)) > timeout = true; > if (timeout) > ++fatal; > else > fatal = 0; > if (fatal >= 3) { > printf("MusE: WatchDog: fatal error, realtime task > timeout\n"); > printf(" (%d,%d-%d) - stopping all services\n", > watchMidi, watchAudio, fatal); > break; > } > > So I added some printfs to see which condition caused the timeout. It > turned out to be the watchAudio==0 comparison. Being a curious person I > simply commented out that if block. And what happened? > > MusE now works!? No of course it might but only at 10% i bet. I recommend you to get the real problem unless Werner - maybe the only person arround who might tell you the truth - answers to your mail. Try to find the problem, fix it and your safe. > Including the softsynths (except for fluidsynth). The timing is quite > stable so far, so there seems nothing to be badly broken by that primitive > and unqualified hack. Yes it's a hack not a solution unless you fixed a bug what i don't belive yet. > Frank > > Sorry for replying two times to myself, I promise now to wait if there's a > reaction at all to my mails ;) ! This is really no problem! Hope that helps, Joachim |
From: Frank H. <fhe...@ya...> - 2005-04-10 13:15:05
|
On Sunday 10 April 2005 14:45, Joachim Schiele wrote: > > MusE now works!? > > No of course it might but only at 10% i bet. I recommend you to get the > real problem unless Werner - maybe the only person arround who might tell > you the truth - answers to your mail. > Try to find the problem, fix it and your safe. Yes, I know that... and the timing turned out to be bad, too, when I started to use hydrogen as a drum machine. So I guess the only thing I did was to lobotomy MusE's realtime capabilties away. :(:( > > Including the softsynths (except for fluidsynth). The timing is quite > > stable so far, so there seems nothing to be badly broken by that > > primitive and unqualified hack. > > Yes it's a hack not a solution unless you fixed a bug what i don't belive > yet. You're right. Thank's for your reply anyway Frank |
From: Joachim S. <js...@du...> - 2005-04-10 13:25:07
|
On Sunday 10 April 2005 15:13, you wrote: > On Sunday 10 April 2005 14:45, Joachim Schiele wrote: > > > MusE now works!? > > > > No of course it might but only at 10% i bet. I recommend you to get the > > real problem unless Werner - maybe the only person arround who might tell > > you the truth - answers to your mail. > > Try to find the problem, fix it and your safe. > > Yes, I know that... and the timing turned out to be bad, too, when I > started to use hydrogen as a drum machine. So I guess the only thing I did > was to lobotomy MusE's realtime capabilties away. :( > > > > Including the softsynths (except for fluidsynth). The timing is quite > > > stable so far, so there seems nothing to be badly broken by that > > > primitive and unqualified hack. > > > > Yes it's a hack not a solution unless you fixed a bug what i don't belive > > yet. > > You're right. Thank's for your reply anyway Np, try to help as much as i can! I think we have to find a real solution for you. MusE really relays on good timing especially for audio recording! Did you recompile your kernel? What version do you use? cat /proc/version modprobe realtime (with your args) and see what /var/log/syslog or if not existing /var/log/messages says joachim |
From: Frank H. <fhe...@ya...> - 2005-04-10 15:07:08
Attachments:
config.gz
|
On Sunday 10 April 2005 15:24, Joachim Schiele wrote: > Np, try to help as much as i can! Thank you! > I think we have to find a real solution for you. MusE really relays on good > timing especially for audio recording! > > Did you recompile your kernel? What version do you use? > cat /proc/version Linux version 2.6.11-gentoo-r4 (root@FranksDesktop) (gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)) #3 Thu Mar 31 22:21:06 CEST 2005 I'll append the config.gz. > modprobe realtime (with your args) and see what > /var/log/syslog or if not existing /var/log/messages says with realtime-lsm-0.1.1 from sourceforge: # cd realtime-lsm-0.1.1 # insmod ./realtime.ko allcaps=1 any=1 gives Apr 10 16:49:33 [kernel] selinux_register_security: Registering secondary module realtime Apr 10 16:49:33 [kernel] Realtime LSM enabling all capabilities Apr 10 16:49:33 [kernel] Realtime LSM initialized (all groups, mlock=1) realtime-lsm-0.8.5-r1 (which doesn't support capabilties) from the gentoo portage tree gives # rmmod realtime # modprobe realtime Apr 10 16:51:39 [kernel] selinux_register_security: Registering secondary module realtime Apr 10 16:51:39 [kernel] Realtime LSM initialized (all groups, mlock=1) To me that looks unsuspicious. Frank |
From: Frank H. <fhe...@ya...> - 2005-04-12 07:37:39
|
Hi Robert! Thanks for your reply! > I recall having seen these symptoms before, especially with gentoo. > > I think there may be a problem with glibc, specifically with regards to > starting threads. > Please do the following: > Install schedutils (available here: http://rlove.org/schedutils). > > Then start your patched muse and run this as root in a terminal: > for p in /proc/`pidof muse`/task/*; do chrt -p `echo $p |cut -d/ -f5`; done > > On my machine this prints: > pid 8457's current scheduling policy: SCHED_OTHER > pid 8457's current scheduling priority: 0 > pid 8458's current scheduling policy: SCHED_FIFO > pid 8458's current scheduling priority: 99 > pid 8459's current scheduling policy: SCHED_OTHER > pid 8459's current scheduling priority: 0 > pid 8460's current scheduling policy: SCHED_FIFO > pid 8460's current scheduling priority: 80 > pid 8461's current scheduling policy: SCHED_FIFO > pid 8461's current scheduling priority: 9 Here's the output on my system: $ for p in /proc/`pidof muse`/task/*; do chrt -p `echo $p |cut -d/ -f5`; done pid 29963's current scheduling policy: SCHED_OTHER pid 29963's current scheduling priority: 0 pid 29964's current scheduling policy: SCHED_FIFO pid 29964's current scheduling priority: 99 pid 29965's current scheduling policy: SCHED_OTHER pid 29965's current scheduling priority: 0 pid 29966's current scheduling policy: SCHED_FIFO pid 29966's current scheduling priority: 80 pid 29967's current scheduling policy: SCHED_FIFO pid 29967's current scheduling priority: 9 Seems like that's not the cause of the problem. > Meaning that MusE has started five threads, three of which are SCHED_FIFO, > two are SCHED_OTHER. > > Also run: > getconf GNU_LIBPTHREAD_VERSION > > On my system this prints: > NPTL 2.3.3 Here it's $ getconf GNU_LIBPTHREAD_VERSION NPTL 2.3.4 So we just differ in a minor version number. > Please report back the data you get, I can't promise it'll help but it will > atleast be interesting :):) Hope that helps you helping me with my problem! Anything more I can do? Frank |
From: Robert J. <rj...@sp...> - 2005-04-13 16:06:58
|
> Here it's > > $ getconf GNU_LIBPTHREAD_VERSION > NPTL 2.3.4 > > So we just differ in a minor version number. Right, the problem is probably not in this area. /Robert > > > Please report back the data you get, I can't promise it'll help but it > > will atleast be interesting :):) > > Hope that helps you helping me with my problem! > > Anything more I can do? > > Frank > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user -- http://spamatica.se/musicsite/ |
From: Robert J. <rj...@sp...> - 2005-04-11 18:10:03
|
Hi, On Sunday 10 Apr 2005 17:06, Frank Hellmuth wrote: > On Sunday 10 April 2005 15:24, Joachim Schiele wrote: > > Np, try to help as much as i can! > > Thank you! > > > I think we have to find a real solution for you. MusE really relays on > > good timing especially for audio recording! > > > > Did you recompile your kernel? What version do you use? > > cat /proc/version > > Linux version 2.6.11-gentoo-r4 (root@FranksDesktop) (gcc version 3.3.5 > (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)) #3 Thu Mar 31 22:21:06 > CEST 2005 I recall having seen these symptoms before, especially with gentoo. I think there may be a problem with glibc, specifically with regards to starting threads. Please do the following: Install schedutils (available here: http://rlove.org/schedutils). Then start your patched muse and run this as root in a terminal: for p in /proc/`pidof muse`/task/*; do chrt -p `echo $p |cut -d/ -f5`; done On my machine this prints: pid 8457's current scheduling policy: SCHED_OTHER pid 8457's current scheduling priority: 0 pid 8458's current scheduling policy: SCHED_FIFO pid 8458's current scheduling priority: 99 pid 8459's current scheduling policy: SCHED_OTHER pid 8459's current scheduling priority: 0 pid 8460's current scheduling policy: SCHED_FIFO pid 8460's current scheduling priority: 80 pid 8461's current scheduling policy: SCHED_FIFO pid 8461's current scheduling priority: 9 Meaning that MusE has started five threads, three of which are SCHED_FIFO, two are SCHED_OTHER. Also run: getconf GNU_LIBPTHREAD_VERSION On my system this prints: NPTL 2.3.3 Please report back the data you get, I can't promise it'll help but it will atleast be interesting :) Regards, Robert > > I'll append the config.gz. > > > modprobe realtime (with your args) and see what > > /var/log/syslog or if not existing /var/log/messages says > > with realtime-lsm-0.1.1 from sourceforge: > > # cd realtime-lsm-0.1.1 > # insmod ./realtime.ko allcaps=1 any=1 > > gives > > Apr 10 16:49:33 [kernel] selinux_register_security: Registering secondary > module realtime > Apr 10 16:49:33 [kernel] Realtime LSM enabling all capabilities > Apr 10 16:49:33 [kernel] Realtime LSM initialized (all groups, mlock=1) > > realtime-lsm-0.8.5-r1 (which doesn't support capabilties) from the gentoo > portage tree gives > > # rmmod realtime > # modprobe realtime > > Apr 10 16:51:39 [kernel] selinux_register_security: Registering secondary > module realtime > Apr 10 16:51:39 [kernel] Realtime LSM initialized (all groups, mlock=1) > > To me that looks unsuspicious. > > Frank -- http://spamatica.se/musicsite/ |
From: Mark K. <mar...@gm...> - 2005-04-11 18:24:22
|
Since I see some problems I'l tag along if I may... On Apr 11, 2005 11:09 AM, Robert Jonsson <rj...@sp...> wrote: > > > Did you recompile your kernel? What version do you use? > > > cat /proc/version [root@Godzilla root]# cat /proc/version Linux version 2.6.11-0.3.rdt.rhfc2.ccrma (mac...@cm...) (gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7)) #1 Tue Mar 22 05:06:00 EST 2005 > Then start your patched muse and run this as root in a terminal: > for p in /proc/`pidof muse`/task/*; do chrt -p `echo $p |cut -d/ -f5`; done [root@Godzilla root]# for p in /proc/`pidof muse`/task/*; do chrt -p `echo $p |cut -d/ -f5`; done sched_setscheduler: Invalid argument failed to set pid 0's policy [root@Godzilla root]# Does the Planet kernel not have somethign you are expecting? > Also run: > getconf GNU_LIBPTHREAD_VERSION > [root@Godzilla root]# getconf GNU_LIBPTHREAD_VERSION NPTL 0.61 [root@Godzilla root]# - Mark |
From: Robert J. <rj...@sp...> - 2005-04-13 16:06:03
|
Hi, On Monday 11 Apr 2005 20:24, Mark Knecht wrote: > Since I see some problems I'l tag along if I may... > > On Apr 11, 2005 11:09 AM, Robert Jonsson <rj...@sp...> wrote: > > > > Did you recompile your kernel? What version do you use? > > > > cat /proc/version > > [root@Godzilla root]# cat /proc/version > Linux version 2.6.11-0.3.rdt.rhfc2.ccrma > (mac...@cm...) (gcc version 3.3.3 20040412 (Red Hat > Linux 3.3.3-7)) #1 Tue Mar 22 05:06:00 EST 2005 > > > Then start your patched muse and run this as root in a terminal: > > for p in /proc/`pidof muse`/task/*; do chrt -p `echo $p |cut -d/ -f5`; > > done > > [root@Godzilla root]# for p in /proc/`pidof muse`/task/*; do chrt -p > `echo $p |cut -d/ -f5`; done > sched_setscheduler: Invalid argument > failed to set pid 0's policy > [root@Godzilla root]# > > Does the Planet kernel not have somethign you are expecting? Sorry, don't have any idea where this comes from. For reference, what buffer settings are you trying to use it with? I saw you sent a message to the jack list about using buffers 16x2. Which is very small :) and quite possibly flawed with MusE. > > > Also run: > > getconf GNU_LIBPTHREAD_VERSION > > [root@Godzilla root]# getconf GNU_LIBPTHREAD_VERSION > NPTL 0.61 Ok, good to know, the search goes on. /Robert > [root@Godzilla root]# > > - Mark -- http://spamatica.se/musicsite/ |
From: Mathias L. <mat...@br...> - 2005-04-12 20:12:16
|
Sorry for coming in late.... About the watchMidi-thing you commented out... Since MusE uses realtime priority threads, in case things go wrong, MusE might lock up the entire system. To avoid that, there's a watchdog thread running with higher priority than all the others, making sure that they don't stop responding, so watchMidi is a variable that is reset to 0 by the watchdog after the sequencer-thread increases it with 1. If f.ex. the sequencer thread is not responding in time, the watchMidi is 0 and the watchdog terminates MusE (this is not the entire truth about the watchdog, but something like this I think). >From your output below it indeed looks as if you've "got your priorities right", but apparently, there's something that's not working as it should (probably causing the bad timing). Unfortunately, I'm not familiar with the 2.6-kernels and their patches/modules for realtime capabilities... :-/ I remember that once upon a time there was bugs in glibc and thread priorities when running suid binaries as normal user - don't have a clue at all if this has anything to do with it. /Mathias tis 2005-04-12 klockan 09.37 skrev Frank Hellmuth: > Hi Robert! > > Thanks for your reply! > > > I recall having seen these symptoms before, especially with gentoo. > > > > I think there may be a problem with glibc, specifically with regards to > > starting threads. > > Please do the following: > > Install schedutils (available here: http://rlove.org/schedutils). > > > > Then start your patched muse and run this as root in a terminal: > > for p in /proc/`pidof muse`/task/*; do chrt -p `echo $p |cut -d/ -f5`; done > > > > On my machine this prints: > > pid 8457's current scheduling policy: SCHED_OTHER > > pid 8457's current scheduling priority: 0 > > pid 8458's current scheduling policy: SCHED_FIFO > > pid 8458's current scheduling priority: 99 > > pid 8459's current scheduling policy: SCHED_OTHER > > pid 8459's current scheduling priority: 0 > > pid 8460's current scheduling policy: SCHED_FIFO > > pid 8460's current scheduling priority: 80 > > pid 8461's current scheduling policy: SCHED_FIFO > > pid 8461's current scheduling priority: 9 > > Here's the output on my system: > > $ for p in /proc/`pidof muse`/task/*; do chrt -p `echo $p |cut -d/ -f5`; done > pid 29963's current scheduling policy: SCHED_OTHER > pid 29963's current scheduling priority: 0 > pid 29964's current scheduling policy: SCHED_FIFO > pid 29964's current scheduling priority: 99 > pid 29965's current scheduling policy: SCHED_OTHER > pid 29965's current scheduling priority: 0 > pid 29966's current scheduling policy: SCHED_FIFO > pid 29966's current scheduling priority: 80 > pid 29967's current scheduling policy: SCHED_FIFO > pid 29967's current scheduling priority: 9 > > Seems like that's not the cause of the problem. > > > Meaning that MusE has started five threads, three of which are SCHED_FIFO, > > two are SCHED_OTHER. > > > > Also run: > > getconf GNU_LIBPTHREAD_VERSION > > > > On my system this prints: > > NPTL 2.3.3 > > Here it's > > $ getconf GNU_LIBPTHREAD_VERSION > NPTL 2.3.4 > > So we just differ in a minor version number. > > > Please report back the data you get, I can't promise it'll help but it will > > atleast be interesting :):) > > Hope that helps you helping me with my problem! > > Anything more I can do? > > Frank > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user |
From: Frank H. <fhe...@ya...> - 2005-04-13 12:23:15
|
On Tuesday 12 April 2005 22:12, Mathias Lundgren wrote: >From your output below it indeed looks as if you've "got your priorities > right", but apparently, there's something that's not working as it > should (probably causing the bad timing). Unfortunately, I'm not > familiar with the 2.6-kernels and their patches/modules for realtime > capabilities... :-/ I remember that once upon a time there was bugs in > glibc and thread priorities when running suid binaries as normal user - > don't have a clue at all if this has anything to do with it. Hmmm... that doesn't sound like a solution will be available soon. :( But if it would be a general kernel 2.6 related issue, I wouldn't think that just so few people are affected. Do you think it would be helpfull to take a closer look at the gentoo 2.6 patch-set against the vanilla kernel? Or do you think it's more likely glibc that causes the problem? Frank |
From: Robert J. <rj...@sp...> - 2005-04-13 16:31:39
|
On Wednesday 13 Apr 2005 14:22, Frank Hellmuth wrote: > On Tuesday 12 April 2005 22:12, Mathias Lundgren wrote: > >From your output below it indeed looks as if you've "got your priorities > > > > right", but apparently, there's something that's not working as it > > should (probably causing the bad timing). Unfortunately, I'm not > > familiar with the 2.6-kernels and their patches/modules for realtime > > capabilities... :-/ I remember that once upon a time there was bugs in > > glibc and thread priorities when running suid binaries as normal user - > > don't have a clue at all if this has anything to do with it. > > Hmmm... that doesn't sound like a solution will be available soon. :( > But if it would be a general kernel 2.6 related issue, I wouldn't think > that just so few people are affected. Do you think it would be helpfull to > take a closer look at the gentoo 2.6 patch-set against the vanilla kernel? > Or do you think it's more likely glibc that causes the problem? I think the timer tick isn't happening for one reason or the other. Which is very wierd, especially as you mention having tried both 0.7.1 and 0.8pre1 (cvs). They do infact use different timing sources, 0.7.1 uses ALSA and cvs uses RTC. And no additional errors were printed in the console? For instance, unable to open /dev/rtc ? Some todos if you want to try some more: Check that you have a /dev/rtc device, ('ls /dev/rtc' will do). Try 'cat /dev/rtc' and see anything is if printed, normally it hangs if I recall correctly. Another thing to try is to edit: muse-0.7.1/muse/driver/timerdev.h and change the line: #define TIMER_DEBUG 0 to 1 and edit: muse-0.7.1/muse/midiseq.cpp: around line 395 Change the line containing MidiSeq::ticker++ > 100000 so the number is 100 Now recompile and start muse again. Now there should be 'tick!' written once in a while before muse quits. That's all I can think of at the moment. Regards, Robert > > Frank > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Lmuse-user mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-user -- http://spamatica.se/musicsite/ |
From: Mathias L. <mat...@br...> - 2005-04-13 17:19:15
|
ons 2005-04-13 klockan 14.22 skrev Frank Hellmuth: > On Tuesday 12 April 2005 22:12, Mathias Lundgren wrote: > > >From your output below it indeed looks as if you've "got your priorities > > right", but apparently, there's something that's not working as it > > should (probably causing the bad timing). Unfortunately, I'm not > > familiar with the 2.6-kernels and their patches/modules for realtime > > capabilities... :-/ I remember that once upon a time there was bugs in > > glibc and thread priorities when running suid binaries as normal user - > > don't have a clue at all if this has anything to do with it. > > Hmmm... that doesn't sound like a solution will be available soon. :( > But if it would be a general kernel 2.6 related issue, I wouldn't think that > just so few people are affected. Do you think it would be helpfull to take a > closer look at the gentoo 2.6 patch-set against the vanilla kernel? Or do > you think it's more likely glibc that causes the problem? > > Frank > Impossible to say. I might be totally off track here, too, but it looks like for some reason you're not getting the capabilities that the stuff you're having promises. I think it was Robert that first told me about the glibc-issue w scheduling priorities, and IIRC, you could tell if there was a problem with that schedutils test. /Mathias |