[PD] /etc/security/limits.conf WAS Re: Pd-0.39.2-extended-rc4 released on ubuntu

[Hans-Christoph Steiner]

Sounds like a big buffer by default is the best option for the  
package.  Maybe something like 50ms, that should be big enough to  
cover all but the really heinous hardware.  Then docs about setting  
up for tight timing, limits.conf, -rt, etc.

.hc

On Jul 18, 2007, at 2:03 PM, Miller Puckette wrote:

> I think it's best to put this on the wiki as a possible tweak.   
> There are
> too many 'reasonable' variations.  For instance, on personal  
> machines I use
> my own login name instead of a group 'audio' (for simplicity); also,
> I don't touch the 'nice' settings.
>
> I've never had stability problems with "-rt" and use it in all my  
> routine
> work.  My idea is to make my development environment exactly the  
> same as
> the performance environment to reduce the chance of surprises.   
> However,
> if you're in the habit of having Pd spawn sub-processes, "-rt" is  
> dangerous.
> I'm not sure if "renicing" is safe or not; I never do it myself,  
> preferring
> to count on the RTPRIO setting to take care of things.
>
> cheers
> Miller
>
> On Wed, Jul 18, 2007 at 06:52:11PM +0200, Frank Barknecht wrote:
>> Hallo,
>> hard off hat gesagt: // hard off wrote:
>>
>>>>> The rlimits approach will soon be common knowledge among all Linux
>>>> audio users anyway.
>>>
>>>> Not everyone wants to learn about this stuff.  Some people just  
>>>> want
>>>> to install Ubuntu Studio and make music.
>>>
>>> hans, i am so much on your side here.   ..although i'd say:   
>>> 'some of us
>>> just want to install ubuntu studio, make massively complicated pd  
>>> patches,
>>> and then make music.'
>>
>> Others want to make massive 36-channel recordings with Ardour, run
>> 128-voice synthesiziers with SuperCollider, rock the party with  
>> Mixxx,
>> play Csound5 in realtime, edit midi arrangements with MusE, run a  
>> live
>> webradio stream with icecast2 while OTOH others want to harden their
>> webserver with port-knock logins or set fierce limits for all users.
>> Should all these packages fight for who should edit limits.conf and
>> whose edits will finally survive?
>>
>> This is not about if users should learn how to edit limits.conf or
>> not, this is about playing fair with other pieces of software
>> installed in a distribution.
>>
>> If it was only about making editing limits.conf easier, here's a way:
>> Just run this script as root/under sudo:
>>
>> #!/bin/sh
>> if test -w /etc/security/limits.conf
>> then
>>     read -p "Update /etc/security/limits.conf? [yN]: " DOIT
>>     if test "$DOIT" = "y"
>>     then
>>         echo "@audio   -  nice     -10" >> /etc/security/limits.conf
>>         echo "@audio   -  rtprio   99" >> /etc/security/limits.conf
>>         echo "@audio   -  memlock  unlimited" >> /etc/security/ 
>> limits.conf
>>         echo "/etc/security/limits.conf updated successfully!"
>>         echo "You need to logout completely and login again to"
>>         echo "activate changes."
>>         echo "Also make sure you're in group \"audio\"."
>>     else
>>         echo "Okay, doing nothing"
>>     fi
>> else
>>     echo "/etc/security/limits.conf not writable, giving up"
>> fi
>>
>> # EOF
>>
>> Ciao
>> -- 
>>  Frank Barknecht                 _ ______footils.org_ __goto10.org__
>>
>> _______________________________________________
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
>> listinfo/pd-list
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list




------------------------------------------------------------------------ 
----

You can't steal a gift. Bird gave the world his music, and if you can  
hear it, you can have it. - Dizzy Gillespie