Dave, Paul (and others) answered your questions already. These are just my comments on the same ideas... >> 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 ? For an end-user recommendation: (1) Run with memory locked unless you don't have enough memory. (2) Memory is cheap, buy more if you can afford it. (3) Otherwise, experiment with -u and -m to see if one of them works adequately. For me, both options are about the same in practice. But, I don't use VST, so your results may be more like Paul's. The -m option came about mostly because of OSX, which does not support memory locking and hence always runs without it. It turns out that the realtime thread context seldom gets paged out. Those pages tend to stay "hot" in the VM sense. I rarely see any realtime glitches running with -m, but they could happen on a machine with tightly constrained memory. Hence, experiment. Actual memory usage should be highest with all memory locked, lower with -u and lowest with -m. >> 2) I understand audio dithering conceptually, but what would be a >> typical situation when I would enable it in JACK ? I generally don't use it with my high-quality M-Audio PCI cards, which support 24-bit directly. But, sometimes it is useful to hear approximately what my music will sound like when converted to CD format. For that, I use JACK to audition the sound, and ardour to actually convert the samples. >> 3) Is there any particular good reason a user would *not* want -R enabled ? Mostly only when one has latency problems. There may be other reasons, but I can't think of any right now. It has been such a pain for so long to get a stable, low-latency kernel running properly (including access permissions), that most people needed it. Recent kernel development has reached the point where this is less of a problem. Within six months or so, we should see that trickling down into mainstream distributions. Maybe in a year or so, most end users won't have to worry much about that part of the problem any more. But, there are other sources of realtime latency in PC systems: IRQ assignments, video cards, misconfigured or misdesigned devices, etc. So, these problems will never completely disappear. (There is a business opportunity building and supporting well-tuned low-latency PC audio hardware.) >> 4) Regarding the "Force 16-bit" option: When would a normal user want to >> activate this option ? To summarize: not normally needed, but some screwy hardware requires it. -- joq
