[PD] pd crash oddity (and a workaround)

[Ivica Ico Bukvic]

Greetings all,

It has come to my attention recently that when the following conditions are
true, Pd (pd-extended 0.41.4 with custom patches) freezes (this is on Ubuntu
9.04 Linux with custom 2.26.29 rt kernel):

1) a low-power cpu (in this case Atom 1.6GHz) is using ondemand cpu
governor, thus in this case running for the most part at 800MHz
2) jackd is started with any kind of settings (including any priority level
from default(0) to 89 and even -Z option)
3) pd is started and auto-connects to jack
4) a more complex patch is opened (not sure what the exact metrics for this
is, but the patch in question is simply a GUI element that has bunch of
sliders and is embedded as an abstraction into the canvas)

When this happens, more often than not Pd freezes when opening the patch
requiring forceful shutdown. When ran from command line, Pd outputs pd
watchdog warning as well as zombified notification, even though sometimes it
continues without any observable problems. Yet, the -Z option on the Jack
side does nothing to abate this.

I tried disabling SIGHUP in the s_watchdog.c and recompiling Pd but this has
not had much of an effect on this either.

Among ugly workarounds we have:

1) start pd without having it connect to jack, then load the patch (which
works always fine when pd is not connected to jack while loading it), and
then manually connect to jack. Of course, this also means that every time
you need to unload the patch and load a new one, you need to change audio
driver to something other than jack, then load the patch, and then
reconnect. Having jack connection even if audio is not being computed still
freezes just the same.

2) separate gui part from audio and run 2 instances of Pd. This is however
very confusing as in Gnome one has a difficult time distinguishing which pd
is which, particularly since window locations for both instances are
initially the same. This also adds overhead in maintaining the patches (e.g.
using MIDI/OSC/network packets to exchange data between two instances, or
some other ugly workaround).

What did work, however (at least so far), and seemed so far the least "ugly"
solution is having cpu run at full-speed or using performance governor for
cpufreq scaling. In this case, the problem does not occur and the patch
loads just fine (although this may end-up being a problem for a humongous
patch that may tax the cpu even at full speed--no idea if this is the case).
I thought initially that this may have to do with the governor being too
conservative with ramping-up of the cpu speed (meaning the processes would
get too starved before the cpu spikes thus causing unexpected results during
the loading of the patch while pd's jack backend is running), but
adjustments to this setting through the /proc system made no difference so I
suspect this is not the case (although it could be also the issue of how
often the cpu usage is being polled by cpufreq which is something I did not
mess with).

So, the long story short, to streamline average user experience, one could
have a script that qjackctl can run at start and shutdown that automatically
adjusts cpu governor. One way to do this is to install cpufrequtils (sudo
apt-get -y cpufrequtils) and then manually give SUID permissions to
/usr/bin/cpufreq-set (sudo chmod 7455 /usr/bin/cpufreq-set). This is mainly
since it appears that cpufreq-selector appears to hang (it has apparently
done so since Intrepid), making it unwieldy for this purpose.

As an alternative, one could use cpufreqd which is not used in Ubuntu by
default and which allows application-specific ramping but since I wanted to
keep system as close to the out-of-box experience as possible (and avoid
possibly breaking the gnome cpufreq applet and/or altering default
permissions installed by the cpufrequtils), I resorted to a simple c
implementation in hope that would make it hopefully safer than a SUID shell
script. For those who care, below is the ugly code in all its glory:

cpufreq4jack.c
===================BEGIN======================
main(int argc, char** argv) {
	setuid(0);
	if (argc == 1 || argc > 1 && argv[1][0] == '0') {
		system("sh -c \"echo ondemand >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor\"");
	}
	else if (argc > 1 && argv[1][0] == '1') {
		system("sh -c \"echo performance >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor\"");
	}
}
=====================END=====================
Compile the code with "gcc cpufreq4jack.c -o cpufreq4jack"
Then adjust its permissions:

sudo chown root:root cpufrea4jack
sudo chmod 7455 cpufreq4jack

Now you can bury cpufreq4jack executable somewhere in the /usr/bin/ folder
(or somewhere safer if necessary). The last step is to adjust qjackctl's
options (found on the "options" tab) by adding "cpufreq4jack 1" at start
time, and "cpufreq4jack 0" at shutdown and voila!

All this said, I am wondering (if this is indeed the case here) why is GUI
still so strongly tied to the underlying engine in Pd. Couldn't the two be
more separate so that one does not have to deal with these kinds of problems
and/or ugly hacks like running 2 Pd instances concurrently?

Any thoughts/ideas/improvement suggestions are most welcome...

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico at vt.edu
http://www.music.vt.edu/faculty/bukvic/