Hi,
after successful compilation of pd-0.37 (thanks Frank!), pd won't open my patches anymore. I get the regular "watchdog: signaling pd" printout in the console and the opened patch windows stay white without displaying their contents.
Opening the patch with the -noaudio option works. I tried for more than an hour to track down the problem by partially deleting subpatchers but it seems to be a matter of number rather than a specific subpatcher which doesn't work. My guess is that a lot of audio connections and visible arrays make pd hang. The patch still works fine with pd-0.36 (with about 50% of cpu load).
Any ideas how I can get it to work?
-- Orm
Hallo, Orm Finnendahl hat gesagt: // Orm Finnendahl wrote:
after successful compilation of pd-0.37 (thanks Frank!), pd won't open my patches anymore. I get the regular "watchdog: signaling pd" printout in the console and the opened patch windows stay white without displaying their contents.
Opening the patch with the -noaudio option works. I tried for more than an hour to track down the problem by partially deleting subpatchers but it seems to be a matter of number rather than a specific subpatcher which doesn't work. My guess is that a lot of audio connections and visible arrays make pd hang. The patch still works fine with pd-0.36 (with about 50% of cpu load).
Any ideas how I can get it to work?
Some guesses: try the various sound systems: -alsa, -oss, -jack, also try without loadbang -noloadbang and without realtime scheduling.
I suppose you're normally using Jack, because I remember, that you have the HDSP. With Jack, I've found, that some tweaks of the Jack code are needed: In s_audio_jack.c there is a call to report an error inside the jack_process function:
} else { /* PD could not keep up ! */
if (jack_started) sys_log_error(ERR_RESYNC);
Remove this as in:
} else { /* PD could not keep up ! */
// don't call log_error in jack process:
// if (jack_started) sys_log_error(ERR_RESYNC);
Another change that might help is in s_inter.c. Edit this:
p2 = sched_get_priority_max(SCHED_FIFO);
p3 = (higher ? p2 - 1 : p2 - 3);
to be that:
p2 = sched_get_priority_max(SCHED_FIFO);
// p3 = (higher ? p2 - 1 : p2 - 3);
p3 = (higher ? p1 + 3 : p1 + 1);
ciao
Frank Barknecht _ ______footils.org__
Hi,
thanks a lot Frank. Leaving away the -rt flag makes it work as does the second change you suggest (see below).
I only wonder whether it is better to use pd-0.36 without this change, or pd-0.37 with the change or whether there are means to change the patch in a way that it works without any changes in the sources of pd-0.37.
-- Orm
Am 15. Februar 2004, 11:38 Uhr (+0100) schrieb Frank Barknecht:
I suppose you're normally using Jack, because I remember, that you have the HDSP.
That's correct.
Remove this as in:
} else { /* PD could not keep up ! */ // don't call log_error in jack process: // if (jack_started) sys_log_error(ERR_RESYNC);
That doesn't help.
p2 = sched_get_priority_max(SCHED_FIFO); // p3 = (higher ? p2 - 1 : p2 - 3);p3 = (higher ? p1 + 3 : p1 + 1);
That helps. With that change, I can start up the patch with the -rt flag.
Hallo, Orm Finnendahl hat gesagt: // Orm Finnendahl wrote:
I only wonder whether it is better to use pd-0.36 without this change, or pd-0.37 with the change or whether there are means to change the patch in a way that it works without any changes in the sources of pd-0.37.
Well, that's a matter of taste ;)
I'm sure, these changes will find their way into the next release anyways. But there are some changes in the private API of Pd which some externals nevertheless use. For example, my knob externals doesn't work with Pd-0.37 yet. Still I do prefer 0.37 now, especially with Jack, where after doing the two changes, 0.37 works much better here than ever before. I always had problems with graphics intensive patches and Jack, and while they aren't gone (they are planned to go away with 0.38) they don't lead to a Jack crash or Pd hang anymore, they just produce some clicks.
ciao
Frank Barknecht _ ______footils.org__
-
Frank Barknecht -
Orm Finnendahl