[linux-audio-user] JACK configuration: Preventing system lockups

[Dave Phillips]

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