5 Mar
2010
5 Mar
'10
7:47 a.m.
Hi,
As I heard from the Debian jackd maintainer:
In Debian testing/ squeeze and very likely in Ubuntu lucid, it's not
neccesary anymore to manual edit /etc/security/limits.conf! It's been
automatically done by jackd in /etc/security/limits.d/audio.conf and it
will conflict with /etc/security/limits.conf.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507248
Such things are good to know if you're member of the LAU community, and
I feel communication is lacking often with these kind of things...
\r
5 Mar
5 Mar
8:57 a.m.
On 03/05/2010 12:46 PM, rosea grammostola wrote:
Hi,
As I heard from the Debian jackd maintainer:
In Debian testing/ squeeze and very likely in Ubuntu lucid, it's not
neccesary anymore to manual edit /etc/security/limits.conf! It's been
automatically done by jackd in /etc/security/limits.d/audio.conf and it
will conflict with /etc/security/limits.conf.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507248
Such things are good to know if you're member of the LAU community, and
I feel communication is lacking often with these kind of things...
\r
This applies also for Ubuntu Lucid, I checked the source package of JACK
and it contains a debconf template to install the audio.conf file. What
I find weird is that this was introduced in Sid over half a year ago
according to the bug report? It's not in Karmic though.
Best,
Jeremy
9:09 a.m.
New subject: changing for editing /etc/security/limits.conf in debian testing (ubuntu lucid)
On Fri, Mar 5, 2010 at 12:46 PM, rosea grammostola <
rosea.grammostola(a)gmail.com> wrote:
Hi,
As I heard from the Debian jackd maintainer:
In Debian testing/ squeeze and very likely in Ubuntu lucid, it's not
neccesary anymore to manual edit /etc/security/limits.conf! It's been
automatically done by jackd in /etc/security/limits.d/audio.conf and it
will conflict with /etc/security/limits.conf.
Such things are good to know if you're member of
the LAU community, and
I feel communication is lacking often with these kind of things...
Thank you. I have just installed lucid daily build. I had already added the
"rtprio 99" and "memlock unlimited" lines to
/etc/security/limits.conf even
if, surprisingly for me, jackd does start with the -R option. I will undo it
before I restart the computer.
$ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
$ cat /etc/security/limits.d/audio.conf
# generated by jackd's postinst.
#
# Do not edit this file by hand, use
#
# dpkg-reconfigure -p high jackd
#
# instead.
@audio - rtprio 99
@audio - memlock unlimited
#@audio - nice -19
I wonder about the nice value. It is there but commented out.
jackaudio.orgdon't even mention it. What is it for?
Cheers! Pablo
9:13 a.m.
On 03/05/2010 02:09 PM, Pablo Fernandez wrote:
I wonder about the nice value. It is there but commented out.
jackaudio.org <http://jackaudio.org> don't even mention it. What is it for?
Cheers! Pablo
Hello Pablo,
It's to 'renice' (prioritise) processes. But since prioritising
processes with rtprio works better the nice setting is not necessary
anymore afaik.
Best,
Jeremy
9:24 a.m.
New subject: changing for editing /etc/security/limits.conf in debian testing (ubuntu lucid)
On Fri, Mar 5, 2010 at 8:13 AM, Jeremy <jeremy(a)autostatic.com> wrote:
On 03/05/2010 02:09 PM, Pablo Fernandez wrote:
not pick on you jeremy, just wanting to make it more likely that
people find this via google: .... no! renice has NEVER been the right
way to make audio work. the fact that it happens, in a few cases, to
have some beneficial impact has apparently misled some people who
don't understand how this all works. nice and renice have absolutely
nothing to do with making sure that audio plays correctly. the
capability that they represent should not be used for this purpose,
and people who spread around patches to limits.conf that include it
are simply confusing people with an error.
--p
I wonder about the nice value. It is there but commented out.
jackaudio.org <http://jackaudio.org> don't even mention it. What is it for?
Cheers! Pablo
Hello Pablo,
It's to 'renice' (prioritise) processes. But since prioritising
processes with rtprio works better the nice setting is not necessary
anymore afaik.
9:46 a.m.
On 03/05/2010 02:24 PM, Paul Davis wrote:
On Fri, Mar 5, 2010 at 8:13 AM, Jeremy
<jeremy(a)autostatic.com> wrote:
Hello Paul,
No problem, I already chose generic wording because I knew nice wasn't
necessary, but not exactly why. Now it's all clear. Thanks!
Jeremy
On 03/05/2010 02:09 PM, Pablo Fernandez wrote:
not pick on you jeremy, just wanting to make it more likely that
people find this via google: .... no! renice has NEVER been the right
way to make audio work. the fact that it happens, in a few cases, to
have some beneficial impact has apparently misled some people who
don't understand how this all works. nice and renice have absolutely
nothing to do with making sure that audio plays correctly. the
capability that they represent should not be used for this purpose,
and people who spread around patches to limits.conf that include it
are simply confusing people with an error.
--p
I wonder about the nice value. It is there but commented out.
jackaudio.org <http://jackaudio.org> don't even mention it. What is it for?
Cheers! Pablo
Hello Pablo,
It's to 'renice' (prioritise) processes. But since prioritising
processes with rtprio works better the nice setting is not necessary
anymore afaik.
9:16 a.m.
New subject: changing for editing /etc/security/limits.conf in debian testing (ubuntu lucid)
On Fri, Mar 5, 2010 at 8:09 AM, Pablo Fernandez <pablo.fbus(a)gmail.com> wrote:
I wonder about the nice value. It is there but
commented out. jackaudio.org
don't even mention it. What is it for?
its a mistake that has been propagated around the net for a few years.
it has absolutely nothing useful to do with realtime, low latency
audio and should not be used by apps or system configuration for this
purpose. its very unfortunate that this myth took hold.
5452
days inactive
5452
days old
linux-audio-user@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Jeremy -
Pablo Fernandez -
Paul Davis -
rosea grammostola