7 Feb
2006
7 Feb
'06
2:02 a.m.
On Tuesday 07 February 2006 03:39, Lee Revell wrote:
On Mon, 2006-02-06 at 21:30 -0500, Lee Revell wrote:
> On Sat, 2006-02-04 at 15:49 -0500, Dana Olson wrote:
> > I hope you can get this into Breezy. There is a discussion on this
> > page as well, where I learned the steps from:
>
> It's looking good - Matt Zimmermann has instructed the Ubuntu developers
> to review and merge the patches.
Great! Thanks for your efforts in promoting this!
Since it looks like this is happening the next
question is, what do we
thing is a sane default config.
IMHO it needs to be secure OOTB, but we don't want to make users
edit /etc/security/limits.conf, I propose that we
ship /etc/security/limits.conf with the "audio" group set up for
realtime access, but do not add the default user to this group at
install time.
If Ubuntu already places the default user in group "audio", I think we
need to use another group "realtime".
So all that's needed for JACK in realtime mode is "gpasswd -a joeuser
realtime".
I'm fine with both. I recently installed Dapper, it did put me in the audio
group. Btw, I wouldn't be much concerned to have rtprio set by default. Worst
thing that can happen is the user hogging the CPU. Jackd has it's watchdog
preventing a client from doing so, and Ubuntu kernels ship with
CONFIG_MAGIC_SYSRQ=y, so SysRq-n is available as a last resort.
If we don't want to make the user edit /etc/security/limits.conf, the limits
themselves should be well discussed, too.
I have rtprio 80, is just enough to run jackd (currently; it used to be 70).
Would that be generally ok, or should it be more?
memlock is more difficult. I have memlock 700000, but that's for my hardware
and needs (I'm using BruteFIR with many and long filters, so I need lots of
RAM, which I do have on that machine). What's a sensible default?
I don't set nice. Is it needed for audio?
There might also be a good argument that we *do* want
to allow realtime
access to the default user...
Yes, let's see if someone brings one up.
Wolfgang