Yo, <...> just Duh, I've made sure I was in the audio group well before posting. Being in the group doesn't seem to do much. chmod +s jackd appears to do the trick (although it may not have been a very good idea) - but I still can't start jack from the GUI. Cheerio, Mick.

Date: Sat, 21 Nov 2009 19:25:22 +1100 From: cal(a)graggrag.com To: linux-audio-user(a)lists.linuxaudio.org Subject: Re: [LAU] jackd in realtime as user: a no-go in spite of modifying limits.conf Der Mickster wrote: Not sure if this is a possible answer to the question, or perhaps another question altogether, but ... I've struggled with the same issue on a debian system for some time, then discovered this in /etc/pam.d/su - # Sets up user limits, please uncomment and read /etc/security/limits.conf # to enable this functionality. # (Replaces the use of /etc/limits in old login) # session required pam_limits.so So far, I'm still not sure if uncommenting the 'session required pam_limits.so' line actually solves the problem, but I am curious. cheers. (I dumbly sent this to just the op instead of 'reply all', so fwiw I'm repeating it to the list) _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

[ ... ] ... in /etc/pam.d/su - # Sets up user limits, please uncomment and read /etc/security/limits.conf # to enable this functionality. # (Replaces the use of /etc/limits in old login) # session required pam_limits.so

Yes, that one is only when you do not use a PAM-enabled login, i.e you log in via VC. Probably 4/5 login managers are PAM-enabled, or maybe even 5/5.

Have you tried modifying /etc/udev/rules.d/something (debian/ubuntu) or /etc/security/console.perms.d/60-raw1394.perms (fedora)? Make sure you assign your security group (audio?) to the /dev/raw1394 device. -Scott _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user

On Mon, Dec 13, 2010 at 10:41 PM, Danni Coy &lt;danni.coy(a)gmail.com&gt; wrote: see http://jackaudio.org/linux_group_sched Natty is basically not usable by regular users for realtime scheduling. Conversations about this are ongoing. _______________________________________________ Linux-audio-user mailing list Linux-audio-user(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user

On Tue, Dec 14, 2010 at 3:59 AM, linuxdsp &lt;mike(a)linuxdsp.co.uk&gt; wrote: this is wrong. or misleading. there's very little tweaking needed that has anything related to what you describe in the rest of your email. at present, almost all of the issues come from one place and one place only: a general purpose OS considers the hardware as a set of shared resources and thus provides limits on access to them ALL of the tweaking required in Linux has to do with removing, reducing or getting around these limits to access. if you build your own kernel the RT patches and with a 2 line patch that allows RT scheduling for anything and memlock for anything, then you're basically good to go. the old systems you mention basically didn't "schedule" in the way that any unix-class OS does - stuff runs based on strict priorities and doesn't get swapped off the CPU arbitrarily. that's why they were absolutely useless as real world multitasking systems, but did very nicely as 1-task boxes. there is one other class of issues, and these come from hardware components not related to the CPU but to the system bus. when other peripherals illegally or even just inadvisably hog the bus for too long, everyone suffers. sometimes this is caused by the peripheral hardware itself, sometimes by the device driver (authors). this was true in ye olden days too, but it was more catastrophic and made things just not work at all. now, they work but just not very well. finally, note that a general purpose OS does a LOT more than those old machines in terms of policy - managing pluggable devices is a big one that comes to mind, but there is also user management too, network traffic handling and more - and the implementation of these policies does get a bit in the way of a low latency scheduling code path sometimes. that's why the linux RT patch is such a big deal, because it basically gets these things out of the way of the scheduler.

... ALL of the tweaking required in Linux has to do with removing, reducing or getting around these limits to access. if you build your own kernel the RT patches and with a 2 line patch that allows RT scheduling for anything and memlock for anything, then you're basically good to go. ...

On 2010-12-14 15:13, Dave Phillips wrote: This is done when you install jackd (in the file /etc/security/limits.d/audio.conf)

2. Added the necessary tweaks to limits.conf (does it still matter for an rt kernel ?);