Great, all pieces of the puzzle come together with this information.
Source file s_inter.c gives a hint how to check what real time priority level Pd gets. Start from command line with option -verbose. For puredata 0.46.2 (the .deb) Pd window now says:
'priority 6 scheduling enabled.'
In contrast, Miller's build wants at least priority 96 but doesn't get that. Raspbian has by default a file /etc/security/limits.d/audio.conf, with the following content:
@audio - rtprio 95 @audio - memlock unlimited #@audio - nice -19
This was already pointed out by Chris. The file has precedence over /etc/security/limits.conf, therefore the settings you make in limits.conf have no effect. But if you change the rtprio value in audio.conf from 95 to 96, real time priority is granted to Miller's build as well, without any further change. It's that simple in the end.
Not that I understand the details of it. Why is Pd compiled with Jack support happy about priority 6, while it demands 96 otherwise? In practice it seems that priority 6 does a good job on the Pi, but what does it mean on a scale from 1 to 100? Priority 95 is often recommended as maximum value for audio processes, but I've never seen an explanation for the exact numbers.
Katja
On Tue, Dec 9, 2014 at 5:48 PM, Miller Puckette msp@ucsd.edu wrote:
Aha - I just tried Pd on a pi with recent raspian and... problems. I'm in the middle of waiting for a new compilation but I _think_ there are 2 problems happening at once: first off, priority 98 (which Pd's watchdog asks for) seems to be reserved for root. I was able to get priority 96 with no problem. It looked like I had to either add the usual lines to /etc/security/limits.conf:
- rtprio 99
- memlock 1000000000
(that's very permissive) or do the following:
chgrp audio pd/bin/pd pd/bin/pd-watchdog chmod 2755 pd/bin/pd pd/bin/pd-watchdog
AND do one of the following: change the Pd source code, s_inter.c:
#ifdef USEAPI_JACK p3 = (higher ? p1 + 7 : p1 + 5); #else p3 = (higher ? p2 - 1 : p2 - 3); #endif
to just:
p3 = (higher ? p1 + 7 : p1 + 5);
(I still have to think about what level is really appropriate)
OR just compile with JACK support - that's why the "debs" worked, I think. With JACK support Pd asks for a lower RT priority that the pi is willing to give it.
More later...
Miller
On Wed, Dec 03, 2014 at 01:18:18PM +0100, katja wrote:
On Wed, Dec 3, 2014 at 9:37 AM, IOhannes zmölnig <zmoelnig at iem.at> wrote:
Am 03. Dezember 2014 03:20:49 MEZ, schrieb katja <katjavetter at gmail.com>:
Following IOhannes' guidelines in an earlier thread I built the .deb packages from jessie source. That works great, but still it's quite a detour and in particular for new users there should be an easier way to get pd working properly on Raspberry Pi.
How about making your .deb available via apt.puredata.info?
A decent backport available from a logical place would be most convenient indeed. So far I was unable to build it with gpg verification. Also it's not a single .deb but a set of seven, which must be installed with dpkg. Package managers like apt-get, gdebi, Synaptic will pull 0.43 core, gui etcetera as puredata dependencies when you're on wheezy. This could probably be solved by editing dependency specs in debian/control, but still it would be confusing to have those .debs on the apt.puredata.info/releases list, since many people download from there manually. Maybe if there would be something like apt.puredata.info/backports/raspbian_wheezy?
There's no wheezy-backports in the Raspbian archive (due to lack of human resources). Raspbian maintainers try to stay close to wheezy but pull in from sid or make their own modifications if necessary (see:http://elinux.org/Raspbian). This brings me to another idea: if we (I mean Pd community) verify that puredata 0.46.2 is to be preferred over 0.43 for Raspberry Pi, they could pull in puredata 0.46.2 for wheezy. In the meantime could upload my unofficial backport somewhere to facilitate testing.
Katja