On Wed, Jul 13, 2011 at 11:56, cyrille henry <ch@chnry.net> wrote:
hello,

thanks all for your answer.

I'm now back home, and (thanks to Murphy's law), the problem can't be reproduced.

I noticed a bad (physical) Fire wire connection on the cable after the performance, but now it is ok.
maybe my audio buffer was too small and any other computer activity could break the connection between pd and jack (but not between audacity and jack)

so the only valid hypothesis i can find is :
- too small buffer for jack configuration
- bad pd implementation of jack
- automatic script in ubuntu that start in bad timing (friday 19h30)
- bad priority between pd and ubuntu script

it's just discouraging that thing worked for 60h straight and crash during the 20 min performance.

The only lesson i can find is that "with computer, you can't prove things are working, you can only prove that things don't work".



did anyone ever experience a slow down due to ubuntu automatic script that should run on the background?
how to easily disable them? (cron?)

thanks,
Cyrille

AFAIK, Ubuntu runs crontab through anacrontab, which allows the START_HOURS_RANGE in /etc/anacrontab. You can set it to hours when there are usually no performances.

There is also /etc/security/limits/limits.conf where you can prioritize some groups' jobs. For realtime priority to the audio group (which you have to create and join of course) these settings are recommended (memory limit has to be adjusted to your physical memory and check the 'nice' setting because I'm not sure this is the best):
@audio   -  rtprio     99
@audio   -  memlock    1541733
@audio   -  nice      -19

Andras