Nathaniel Virgo wrote:
> On a related note, is there a JACK configuration HOWTO anywhere?
> Things I am currently mystified by include the meaning of the phrase
> "periods per buffer" and how to tell whether my (cheapo laptop
> internal) soundcard should work better at 44100Hz or 48000.
Hi Nathaniel:
You might want to read the recent traffic on this list in response to
my query re: JACK options and their significance to the normal user.
Lots of helpful stuff there.
I've completed an article about JACK from the user's perspective,
hopefully it will run soon in an upcoming issue of the Linux Journal.
Meanwhile here's the relevant section dealing with JACK's run-time options:
<begin_text>
When you first meet JACK you may be confused by some of its options, so
I've prepared a summary of those options with user-level descriptions.
First we'll look at the parameter settings.
-R, --realtime Starts JACK with realtime scheduler priority. Normally
you will want this option activated, but be aware that it functions only
if you have root status or are running a kernel that grants such status
to a normal user. Kernels from AGNULA/Demudi and Planet CCRMA are
prepared for such status, but any kernel can be patched and modified for
low-latency, with root-user capabilities enabled. See the Resources for
this article for information on configuring and building a low-latency
Linux kernel.
I asked members of the Linux Audio Users mail list whether there might
be good reasons to *not* use the realtime option. I learned that JACK is
still useful on systems without realtime capability, hence the option.
Additionally, realtime capabilities might be unwanted while testing an
application whose realtime performance needed debugged.
-m, --no-mlock Signals JACK to keep memory unlocked. Paul Davis
explained that it could be useful when running JACK in realtime on a
system whose physical RAM is being consumed by JACK and its clients.
Generally speaking, most users will not need to activate this option.
-u, --unlock Unlocks memory claimed by graphics toolkits (GTK, QT,
FLTK, WINE). Again, this option is useful for machines with low amounts
of memory (physical RAM), but it is especially useful for users running
VST/VSTi plugins and other WINE-dependent applications. In some cases
such applications may not run at all until this option is selected. You
might also want to unlock memory held by GTK or QT if you're running
many graphics-intensive applications in a memory-hungry environment.
-s, --softmode Ignores xruns reported by an ALSA driver, making JACK
less likely to disconnect unresponsive ports when run without realtime
status. You might select this option to avoid too-copious error reports.
-S, --shorts Forces JACK's internal processing to 16 bits instead of
the default 32 bits. Bit resolution affects dynamics resolution, so
normally you would prefer the default value. JACK attempts to set the
sample bit resolution to 32, 24, and 16, in that order, reporting
success or failure with each attempt. Users with cards known to work
optimally at 16 bits may want to use this option to avoid the error
reports. Clemens Ladisch also noted that some audio devices offer higher
sample rates or more I/O channels only at the lower sample rate, due to
audio chipsets with limited bandwidth.
-H, --hwmon Enables hardware monitoring of ALSA's capture ports,
providing zero-latency monitoring of audio input. Requires hardware and
device driver support. The jackd man page says this about hardware
monitoring :
"When enabled, requests to monitor capture ports will be
satisfied by creating a direct signal path between audio interface input
and output connectors, with no processing by the host computer at all.
This offers the lowest possible latency for the monitored signal."
Note that this option is currently an ALSA-only option available for the
RME Hammerfall cards and cards based on the ICE1712 chipset (M-Audio
Delta 44/66/1010, Terratec, others). The ALSA soundcard database lists
cards that support hardware monitoring, see this article's Resources for
a link to the database.
-M, --hwmeter Another ALSA-only option. Turns on hardware metering if
your soundcard supports it.
-z, --dither Dithering is a process that minimizes unwanted
side-effects of reducing an audio file's bit-depth. Low-level noise is
mixed into a signal to randomize digital audio quantization errors,
turning audible and unpleasant digital distortion into something more
closely resembling analog noise. According to Paul Davis, dithering is
especially helpful when your soundcard's output is less than 24-bit
resolution and you run JACK at the hardware's real sample rate. Paul
further noted that its a good idea to choose dithering for almost any
consumer-grade hardware, though he added that the sonic difference might
not be very noticeable in the speaker systems usually associated with
consumer-grade soundcards.
-P, --realtime-priority Sets the realtime scheduler priority. Normally
you can leave this setting at its default value of 0.
-p, --port-max Sets the maximum number of JACK output ports. The
default of 128 should be sufficient for most users, but up to 512 ports
can be made available.
-d, --driver Select hardware driver. In fact, you're selecting the
audio system back-end with this option. Currently supported systems
include ALSA, OSS/Linux, CoreAudio, PortAudio, and a dummy system
(useful for testing). Most Linux users will want to choose either ALSA
or OSS.
-r, --rate Sets JACK's sample rate. The default is set to 48000 Hz, but
you may need to experiment to determine the best sample rate for your
system. Lower-powered systems may find it necessary to bring down the
sample rate to improve performance, but generally you want a rate of at
least 44100 Hz for high-quality sound.
-p, --period Specifies the number of frames between JACK's process()
function calls. The default value is 1024, but for low latency you
should set -p as low as possible without producing xruns. Larger periods
yield higher latency, but also make xruns less likely, so you may have
to experiment to find the optimal setting for your hardware.
Incidentally, 'man jackd' tells us that JACK's input latency (measured
in seconds) is --period divided by --rate.
-i, --inchannels
-o, --outchannels
These settings determine the number of I/O channels. The default is
the maximum number supported by your hardware, so for most purposes you
can just use the default values.
-n, --nperiods Specifies the number of periods in the hardware buffer.
The default value is 2. The period size (-p) times --nperiods times four
will equal the JACK buffer size in bytes. By the way, JACK's output
latency (again in seconds) is the number of periods (-n) times the
period size (-p) divided by the sample rate (-r).
-C, --capture
-P, --playback
-D, --duplex
Set JACK to record-only, playback-only, or full duplex status
(simultaneous play and record). This setting can be very important: Some
cards will simply not perform well in duplex mode but work quite well in
the simplex modes. For example, on my laptop JACK will report a steady
stream of xruns if I run the CS4232 chipset in duplex mode. The xruns
disappear if JACK is set for either record-only or playback-only mode.
When trying to find the best settings for lowest latency and fewest
xruns you'll want to focus your adjustments on the period size, the
sample rate, and the number of periods. You may need to experiment to
find the best overall settings.
<end_text>
I hope that helps a little.
Best,
dp
