I am not a real jack-expert but I will try to answer some questions: On 9/5/05, Dave Phillips <dlphillips(a)woh.rr.com> wrote: I think that makes it possibly to run jack on other samplerates than the one supported by the soundcard. this would be needed if you want to open an ardour-session recorded at 96kHz on a PC with only 48kHz-capable hardware... If you want to test/use an jack-app which isn't able to gain realtime-rights due to bad configuration. Or if gaining realtime crashes the pc. If card/driver crash while trying to open the device with more than 16bit? Shouldn't happen but who knows... -- visit http://dillenburg.dyndns.org/~arnold/ --- Wenn man mit Raubkopien Bands wie Brosis oder Britney Spears wirklich verhindern könnte, würde ich mir noch heute einen Stapel Brenner und einen Sack Rohlinge kaufen.

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

On Monday 05 September 2005 08:51 am, Dave Phillips wrote: I may be jumping the gun, but I'm just responding because no one else has tackled the question so far, so I'll try a guess--maybe it will spark someone else with knowledge. (I've never used JACK and haven't tried to read the FAQ and man page.) Could locking the GUI library's memory mean locking the GUI library in memory? In which case locking it in memory might make the GUI respond faster (at the cost of more memory being used (not being swapped out ...), and thus possibly other things operating more slowly. And, conversely, "unlocking" the memory possibly making the GUI run slower (primarily due to swapping) with the possible benefit of other things running faster? Strictly guesses. Randy Kramer