Without real time priority, Pd on Raspberry Pi easily suffers from drop outs. When I run vanilla Pd (for example 0.46-2 executable from Miller's site http://msp.ucsd.edu/software.html) on Raspbian with option -rt, it says that priority scheduling failed, and 'audio I/O error' flashes whenever I move the cursor (I'm not running the Pi headless).
I've noticed that puredata 0.43 as installed from Raspbian repository can run with real time priority even when started by normal user. I wondered where the difference is: in the Pd version or in the fact that puredata from repository is installed and owned by root. Or maybe yet another factor that I can't think of. In any case, I built and installed puredata 0.46.2 from repository source (described here: http://lists.puredata.info/pipermail/pd-list/2014-11/108543.html). This build works with normal user real time priority too.
In order to see if ownership matters, I changed ownership of Miller's build to root. Still it can't run with real time priority when loaded by normal user. Permissions are the same for Miller's build and puredata from repository (-rwxr-xr-x).
Does anyone know a way to run Miller's build with real time priority (apart from running with root permission, which I don't want)? Though I'm happy with puredata 0.46.2 as built from repository source, there may sometimes be a reason to use or test another build.
Katja
Hi all -
The following magic seems to work on any linux distribution: edit /etc/security/limits.conf and add the lines,
- rtprio 99
- memlock 1000000000
I can't remember if I did this on my Pi or not (and don't have it handy right now to check) but I bet I did.
On the other hand, I wonder what Pd extended does. Perhaps it makes itself belong to group 'audio' and runs 'rwxr-sr-x' (the 's' meaning that it confers its group status to whomever runs it). But I thought the 'pi' user was already part of group audio. Also I'm not sure if group audio gets realtime permission by default on Raspian - that's another thing I'd need to dig up my pi to check...
cheers Miller
On Sun, Nov 30, 2014 at 03:12:10PM +0100, katja wrote:
Without real time priority, Pd on Raspberry Pi easily suffers from drop outs. When I run vanilla Pd (for example 0.46-2 executable from Miller's site http://msp.ucsd.edu/software.html) on Raspbian with option -rt, it says that priority scheduling failed, and 'audio I/O error' flashes whenever I move the cursor (I'm not running the Pi headless).
I've noticed that puredata 0.43 as installed from Raspbian repository can run with real time priority even when started by normal user. I wondered where the difference is: in the Pd version or in the fact that puredata from repository is installed and owned by root. Or maybe yet another factor that I can't think of. In any case, I built and installed puredata 0.46.2 from repository source (described here: http://lists.puredata.info/pipermail/pd-list/2014-11/108543.html). This build works with normal user real time priority too.
In order to see if ownership matters, I changed ownership of Miller's build to root. Still it can't run with real time priority when loaded by normal user. Permissions are the same for Miller's build and puredata from repository (-rwxr-xr-x).
Does anyone know a way to run Miller's build with real time priority (apart from running with root permission, which I don't want)? Though I'm happy with puredata 0.46.2 as built from repository source, there may sometimes be a reason to use or test another build.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi,
On 02/12/14 12:55, Miller Puckette wrote:
On the other hand, I wonder what Pd extended does. Perhaps it makes itself belong to group 'audio' and runs 'rwxr-sr-x' (the 's' meaning that it confers its group status to whomever runs it). But I thought the 'pi' user was already part of group audio.
Just double checked this and it is.
Also I'm not sure if group audio gets realtime permission by default on Raspian - that's another thing I'd need to dig up my pi to check...
Is this something that is set in /etc/security/limits.conf? That file is empty except for comments.
Cheers,
Chris.
On 02/12/14 14:20, Chris McCormick wrote:
Also I'm not sure if group audio gets realtime permission by default on Raspian - that's another thing I'd need to dig up my pi to check...
Is this something that is set in /etc/security/limits.conf? That file is empty except for comments.
pi@razor ~ $ cat /etc/security/limits.d/audio.conf
@audio - rtprio 95 @audio - memlock unlimited #@audio - nice -19
So it looks to me like it has the right realtime settings by default.
Cheers,
Chris.
Let me reformulate the mystery: one pd executable is able to get real time priority while another is not, on the same system and started by the same user belonging to group audio.
Raspbian is now indeed distributed with real time priority set by default for audio group (thanks Chris for pointing that out), with user pi as member of audio group. These are the settings which should give real time priority for pd.
But the point is, these settings do not work for a 'local install' like when you put a build from Miller's site in your home dir, even while you do get real time priority for puredata when installed from Raspbian repository, or Pd-extended from apt.puredata.info.
There's good reason to use Miller's latest build on Raspberry Pi. Puredata is debian-packaged vanilla, and wheezy has an outdated version (0.43). For one thing, that version doesn't handle subnormals properly on armv6, which may under certain conditions eat all CPU time. Miller has fixed that almost two years ago. With puredata 0.46.2 from jessie, you have best of both worlds: real time priority and no subnormals bug. However Raspbian jessie is not yet released.
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. If there's a trick to get real time priority for a build in home directory (apart from running as root), that would be great. I've always wondered, how does the system know that puredata is an audio process? Maybe that's where it goes wrong with the local build?
Katja
On Tue, Dec 2, 2014 at 7:36 AM, Chris McCormick chris@mccormick.cx wrote:
On 02/12/14 14:20, Chris McCormick wrote:
Also I'm not sure if group audio gets realtime permission by default on Raspian - that's another thing I'd need to dig up my pi to check...
Is this something that is set in /etc/security/limits.conf? That file is empty except for comments.
pi@razor ~ $ cat /etc/security/limits.d/audio.conf
@audio - rtprio 95 @audio - memlock unlimited #@audio - nice -19
So it looks to me like it has the right realtime settings by default.
Cheers,
Chris.
Am 03. Dezember 2014 03:20:49 MEZ, schrieb katja katjavetter@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?
mfg.ugd.fhj IOhannes
-- Sent from my pdp-11
On Wed, Dec 3, 2014 at 9:37 AM, IOhannes zmölnig zmoelnig@iem.at wrote:
Am 03. Dezember 2014 03:20:49 MEZ, schrieb katja katjavetter@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
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
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
On Wed, Dec 10, 2014, at 02:45 AM, katja wrote:
/etc/security/limits.d/audio.conf, with the following content:
@audio - rtprio 95 @audio - memlock unlimited #@audio - nice -19
Doesn't this file come with jackd? Haven't checked on Raspbian, but this is the case on Debian. This works well on Debian, since user is member of audio group by default.
On Wed, Dec 10, 2014 at 11:31 AM, Kaj Ailomaa zequence@mousike.me wrote:
On Wed, Dec 10, 2014, at 02:45 AM, katja wrote:
/etc/security/limits.d/audio.conf, with the following content:
@audio - rtprio 95 @audio - memlock unlimited #@audio - nice -19
Doesn't this file come with jackd? Haven't checked on Raspbian, but this is the case on Debian. This works well on Debian, since user is member of audio group by default.
You're right Kaj, the file itself says it: 'provided by the jackd package'. So it's not a Raspbian default. How could I miss that while checking and tweaking the file a dozen times.
I wonder why the file sets real time priority 95, while official jackaudio documentation (http://jackaudio.org/faq/linux_rt_config.html) recommends level 99. If level 95 is Debian tradition, it would be best for pd to comply with that level.
Katja
On Wed, Dec 10, 2014, at 04:23 PM, katja wrote:
On Wed, Dec 10, 2014 at 11:31 AM, Kaj Ailomaa zequence@mousike.me wrote:
On Wed, Dec 10, 2014, at 02:45 AM, katja wrote:
/etc/security/limits.d/audio.conf, with the following content:
@audio - rtprio 95 @audio - memlock unlimited #@audio - nice -19
Doesn't this file come with jackd? Haven't checked on Raspbian, but this is the case on Debian. This works well on Debian, since user is member of audio group by default.
You're right Kaj, the file itself says it: 'provided by the jackd package'. So it's not a Raspbian default. How could I miss that while checking and tweaking the file a dozen times.
I wonder why the file sets real time priority 95, while official jackaudio documentation (http://jackaudio.org/faq/linux_rt_config.html) recommends level 99. If level 95 is Debian tradition, it would be best for pd to comply with that level.
Katja
I think there are some different opinions on what is safe, but I wouldn't be able to explain the difference. That is just the way jackd has been packaged for a while I guess :).
On Xubuntu 12.04 I found the same /etc/security/limits.d/audio.conf file with rtprio 95 specified for the audio group. So this setting must be around for quite a while, and not limited to Debian / Raspbian. I can't find any documentation or even mailing list discussion explaining the rationale.
Miller has today responded to this fait accompli with the release of pd 0.46-3 which respects that level, so it can't be bothered by jackd's default setting. Thanks Miller! This irons out a lot of the confusion.
By the way I found that when I created /etc/security/limits.d/puredata.conf it has precedence over /etc/security/limits.d/audio.conf, probably because of it's alpha-numerical rank. Would this for pd users be the most transparent option to set real time priority? Or am I overlooking some drawback?
Katja
On Thu, Dec 11, 2014 at 1:32 PM, Kaj Ailomaa zequence@mousike.me wrote:
On Wed, Dec 10, 2014, at 04:23 PM, katja wrote:
On Wed, Dec 10, 2014 at 11:31 AM, Kaj Ailomaa zequence@mousike.me wrote:
On Wed, Dec 10, 2014, at 02:45 AM, katja wrote:
/etc/security/limits.d/audio.conf, with the following content:
@audio - rtprio 95 @audio - memlock unlimited #@audio - nice -19
Doesn't this file come with jackd? Haven't checked on Raspbian, but this is the case on Debian. This works well on Debian, since user is member of audio group by default.
You're right Kaj, the file itself says it: 'provided by the jackd package'. So it's not a Raspbian default. How could I miss that while checking and tweaking the file a dozen times.
I wonder why the file sets real time priority 95, while official jackaudio documentation (http://jackaudio.org/faq/linux_rt_config.html) recommends level 99. If level 95 is Debian tradition, it would be best for pd to comply with that level.
Katja
I think there are some different opinions on what is safe, but I wouldn't be able to explain the difference. That is just the way jackd has been packaged for a while I guess :).
-
Chris McCormick -
IOhannes zmölnig -
Kaj Ailomaa -
katja -
Miller Puckette