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@vt.edu http://www.music.vt.edu/faculty/bukvic/