5 Sep
2005
5 Sep
'05
1:30 p.m.
1) What will the -m and -u memory options do for a
normal user ? Under
what circumstances is it appropriate to use them ? What exactly does it
mean to unlock a GUI library's memory, and again, how/when does it
benefit the normal user ? Are there reasons a user should not enable
these options ?
-m avoids locking memory into physical RAM. it could theoretically be
useful if running with SCHED_FIFO scheduling (real-time), but when
wanting to avoid possible memory starvation in other applications caused
by JACK and its clients. in general, no user would need to use it.
-u results in memory still being locked into physical RAM (i.e. it
cannot be swapped out to disk, thus avoiding costly page faults when
JACK decides to read or execute something in a section of memory that is
now on disk). this is only necessary for code and data that will be used
by the audio thread - locking down other memory is unnecessary and
causes "memory pressure" in the syste,.
so with -u all libraries that fit certain criteria are unlocked. this is
useful if you have limited RAM available and are using many GUI apps
that use different toolkits and other related libraries. a good example
would be any JACK client that is linked against Wine, which consists of
a huge library, none of which needs to have real-time safe
characteristics - it might be used, but if so, it is used by the GUI,
not the real time audio thread(s). this is also true of the core GTK and
Qt libraries.
2) I understand audio dithering conceptually, but what
would be a
typical situation when I would enable it in JACK ?
you would use dithering if:
a) you are outputting with less than 24 bit resolution AND
b) you are running JACK at the real h/w sample rate
i.e. its good for almost any consumer audio hardware. It does cause a
small increase in CPU use by jackd, and the difference in the sound
quality is marginal in most speaker setups that are likely to be
connected to such audio hardware.
3) Is there any particular good reason a user would
*not* want -R enabled ?
if they do not have an RT-friendly kernel, -R will not help a whole lot,
and they are instead advised to use a large period size. running things
with RT scheduling definitely poses the threat of occasional system
lockups (generally app specific; xmms with the xmms-jack plugin, for
example, can cause problems under some circumstances in which it lives
for a long time). but sure, in general, most people will want -R if
their kernel can support the use of it without requiring root access.
4) Regarding the "Force 16-bit" option: When
would a normal user want to
activate this option ?
clemens addressed this well. There are cards with different capabilities
at 16 bits than at 24 or 32. Because of JACK's testing order, some
people may want to force it to skip the check for 32 or 24 bit mode, and
jump straight to 16 bit operation.