7 Nov
2006
7 Nov
'06
7:39 p.m.
Hi
I'm wondering *exactly* "unlock memory" and "soft mode" (as they
appear
in qjackctl) do? Moreover:
1) Are they advised to be selected or not?
2) Under what circumstances would a check in either be beneficial and
when not?
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
7 Nov
7 Nov
9:09 p.m.
On Wed, 2006-11-08 at 00:39 +0100, Atte André Jensen wrote:
Hi
I'm wondering *exactly* "unlock memory" and "soft mode" (as they
appear
in qjackctl) do? Moreover:
1) Are they advised to be selected or not?
2) Under what circumstances would a check in either be beneficial and
when not?
From the jackd manual:
-u, --unlock
Unlock libraries GTK+, QT, FLTK, Wine.
This means that even if you are running jackd in realtime mode (and thus
locking all memory of the clients into physical RAM), the actual code
from the GTK+, Qt, FLTK, and Wine libraries will be recognised and
unlocked (if the clients link to those libraries) so the kernel can swap
it to disk if it wants. The idea is that the code from those libraries
is typically not used in the JACK clients' realtime threads, so it is OK
to have to wait a while for it to get swapped back to RAM before you use
it. May be useful if you are running low on RAM.
-s, --softmode
Ignore xruns reported by the ALSA driver. This makes JACK
less
likely to disconnect unresponsive ports when running
without
--realtime.
What it says. Probably useful when you are playing live or care more
about keeping all your synths connected than about keeping the xruns at
a minimum (by kicking badly behaved clients from the graph).
--
Lars Luthman - please encrypt any email sent to me if possible
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
8 Nov
8 Nov
3:12 a.m.
Lars Luthman wrote:
so the kernel can swap
it to disk if it wants.
I never run out of ram. In a realtime situation I think this would
generally be a thing to really, really try to avoid. So "unlock memory"
is doing anything the moment I used all my ram and the kernel starts to
swap to disc?
What it says. Probably useful when you are playing
live or care more
about keeping all your synths connected than about keeping the xruns at
a minimum (by kicking badly behaved clients from the graph).
Would that be like a zynaddsubfx being zombified because it takes too
long to save patches? :-)
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
6:12 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Atte André Jensen schrieb:
Lars Luthman wrote:
The swapping is the end of fun anyway ;-).
Still I run jackd with that option enabeled because I experienced much
less trouble with Zynaddsubfx. I doubt that could be an issue with
tcl-tk be it or not - I have this checked and it works better than
whithout....
best
Z
so the kernel can swap
it to disk if it wants.
I never run out of ram. In a realtime situation I think this would
generally be a thing to really, really try to avoid. So "unlock memory"
is doing anything the moment I used all my ram and the kernel starts to
swap to disc? -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFUa1w1Aecwva1SWMRAjYtAKCQSQhuCPMdiCebDPxNK9W+WGOrUACfVp3r
lhBiaXrECB3A1d7sUYVMhHE=
=syQY
-----END PGP SIGNATURE-----
6:58 a.m.
Hartmut Noack wrote:
I have this checked and it works better than
whithout....
Thanks for the report. Others?
--
peace, love & harmony
Atte
http://www.atte.dk | quintet: http://www.anagrammer.dk
| compositions: http://www.atte.dk/compositions
7:28 a.m.
[cc'ing jackit-devel for technical bit]
On Wednesday 08 Nov 2006 01:09, Lars Luthman wrote:
From the jackd manual:
-u, --unlock
Unlock libraries GTK+, QT, FLTK, Wine.
This means that even if you are running jackd in realtime mode (and thus
locking all memory of the clients into physical RAM), the actual code
from the GTK+, Qt, FLTK, and Wine libraries will be recognised and
unlocked (if the clients link to those libraries) so the kernel can swap
it to disk if it wants.
That reminds me -- this option doesn't seem to work any more for me, as the
format of /proc/<pid>/maps appears to have changed slightly since the code
was written. A patch to libjack/client.c is attached below.
I don't pretend to understand the format of the maps file, but there's an
assumption in the original client.c that any line in the file such as
b58db000-b60da000 rwxp b58db000 00:00 0
that has 0 as its final numeric field, will have no further text following
that 0. However, on this machine there are routinely several lines like this
0804e000-08070000 rwxp 0804e000 00:00 0 [heap]
with additional text. When one of those is encountered, the zero is read into
the aptly named "whoknows" variable, the loop continues, the following
iteration's fscanf (which is intended to read the next line) fails as it gets
the spare text as input instead, and parsing ends. This patch just pulls the
fscanf for the path field up a few lines, so it can eat any spare text that
may be present before moving on to the next line. It should be backward
compatible.
I've only tested this against one kernel so far, and it's not a very new one
(2.6.13-something).
Chris
6592
days inactive
6593
days old
linux-audio-user@lists.linuxaudio.org
5 comments
4 participants
participants (4)
-
Atte André Jensen -
Chris Cannam -
Hartmut Noack -
Lars Luthman