Re: [linux-audio-user] help needed with JACK options

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