Miller Puckette wrote:
I changed the implementation of sys_poll_midi at some point, and the new version apparently doesn't work with your card/driver.
a-ha! sometime back in april, i wrote to the list asking about a big performance dive w/ 0.35 and my setup. when i start with -nomidi flag everything is fine - but with midi on, pd idles at about 18% cpu.
so i just took a clue from this thread - this is using test 17 - i edited s_linux.c as Miller suggested and changed the #if0 to #if1
make ended here:
s_linux.c:472: redefinition of sys_poll_midi' s_linux.c:434:sys_poll_midi' previously defined here
make: *** [s_linux.o] Error 1
so i removed the entire first definition of sys_poll_midi, recompiled, and now all is well. midi works, and idle cpusage is back to 0-2%
for what it's worth, this is with a very old midiquest card that works with alsa's mpu401-uart driver.
-bill
To fix it, you could either run "-nomidi" or, if you wanna use MIDI after all, go to s_linux.c, and on line 435 change "#if 0" to "#if 1"... I'll eventually have to add a command line flag to allow people to select between the two versions. But in the meantime I'd be happy to know if that fixes it for your system.
THe reason it worked when you already had another Pd open, was that the previously open Pd opened MIDI, so that the second time you ran Pd it failed to open MIDI and therefore couldn't hang trying to read it...
cheers Miller
On Fri, Jun 28, 2002 at 04:55:28PM -0400, Ben Bogart - FMPM/F1999 wrote:
Alright I made a stupid mistake. When I'm running another PD at the same time (in this case test9) with -nosound then test29 load perfectly. If I quit test4 then test29 does not run again.
So here is the gdb "where" after test29 crashes:
[Switching to Thread 1024 (LWP 7689)] 0x401282e4 in read () from /lib/libc.so.6 (gdb) where #0 0x401282e4 in read () from /lib/libc.so.6 #1 0x4005c65c in __DTOR_END__ () from /lib/libpthread.so.0 #2 0x080bb8d6 in sys_poll_midi () at s_linux.c:490 #3 0x0809357b in sys_pollmidiqueue () at s_unix.c:441 #4 0x0808fcd1 in m_scheduler (nodacs=0) at m_sched.c:440 #5 0x080902e9 in sys_main (argc=1, argv=0xbffff764) at s_main.c:258 #6 0x08094496 in main (argc=1, argv=0xbffff764) at s_entry.c:9 #7 0x4007a9ed in __libc_start_main () from /lib/libc.so.6
hope this new info helps ( I can't explain how having another PD open at the same time helps)
Thanks Ben
On Fri, 28 Jun 2002, Ben Bogart - FMPM/F1999 wrote:
Hmmm very interesting, when I compiled with --enable-debug it works fine, no crashes. then I compiled again the same way I did before and still no crashes... No idea how to explain that one, but I won't complain. :)
thanks Miller.
Ben
On Fri, 28 Jun 2002, Miller Puckette wrote:
Hi Ben,
It would be hard for me to find a bug I can't manifest... would you try something for me? Compile a copy of Pd with configure --enable-debug, then run "gdb ~/pd/bin/pd" (or whatever), hit control-C, and when the GDB prompt comes up, type "where"... this should show where Pd is hanging.
thanks Miller
On Fri, Jun 28, 2002 at 02:39:45PM -0400, Ben Bogart - FMPM/F1999 wrote:
Hello Miller,
I went through all the pd 35 tests and found that only test <= 9 work on my system, all others fail.
Compile works fine, everything seems normal. If I try and run one of the new tests the PD GUI comes up, I get no errors on the console, but only the PD gui seems to work, one can't open a file, but can select a pull down menu. "exit" has no effect, one must ^C out of it.
I'm running the very same Commercial/OSS that I had on my debian system which did not have this problem.
So looks like something change with opening the audio between tests 9-10.
Hope this is enough info to take a closer look.
Thanks Ben
B. Bogart
B. Bogart
B. Bogart