> 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.
