.TH ALSA_IO "1" "!DATE!" "!VERSION!"
.SH NAME
\fBalsa_in\fR, \fBalsa_out\fR \- Jack clients that perform I/O with an alternate audio interface
.SH SYNOPSIS
\fBalsa_in\fR [\fIoptions\fR]
.br
\fBalsa_out\fR [\fIoptions\fR]

.SH DESCRIPTION
A JACK client that opens a specified audio interface (different to the
one used by the JACK server, if any) and moves audio data between its
JACK ports and the interface. alsa_in will provide data from the
interface (potentially for capture); alsa_out will deliver data to it
(for playback).

The audio interface used by alsa_in/alsa_out does not need to be
synchronized with JACK backend (or the hardware it might be using).
alsa_in/alsa_out tries to resample the output stream in an attempt to
compensate for drift between the two clocks.

As of jack-0.116.3 this works almost perfectly. It takes some time, to reach
absolute resample-rate stability. So give it some minutes (its intended to be
running permanently anyways)

.SH OPTIONS
.TP
\fB\-j \fI jack_client_name\fR
.br
Set Client Name.
.TP
\fB\-d \fI alsa_device\fR  
.br
Use this Soundcard.
.TP
\fB\-v\fR  
.br
Verbose, prints out resample coefficient and other parameters useful for debugging, every 500ms.
also reports soft xruns. 
.TP
\fB\-i\fR  
.br
Instrumentation. This logs the 4 important parameters of the samplerate control algorithm every 1ms.
You can pipe this into a file, and plot it. Should only be necessary, if it does not work as
expected, and we need to adjust some of the obscure parameters, to make it work. 
Find me on irc.freenode.org #jack in order to set this up correctly.
.TP
\fB\-c \fI channels\fR  
.br
Set Number of channels.
.TP
\fB\-r \fI sample_rate\fR  
.br
Set sample_rate. The program resamples as necessary.
So you can connect a 44k1 jackd to a soundcard only supporting
48k. (default is jack sample_rate)
.TP
\fB\-p \fI period_size\fR  
.br
Set the period size. It is not related to the jackd period_size.
Sometimes it affects the quality of the delay measurements.
Setting this lower than the jackd period_size will only work, if you
use a higher number of periods. 
.TP
\fB\-n \fI num_period\fR  
.br
Set number of periods. See note for period_size.
.TP
\fB\-q \fI quality\fR  
.br
Set the quality of the resampler from 0 to 4. can significanly reduce cpu usage.
.TP
\fB\-m \fI max_diff\fR  
.br
The value when a soft xrun occurs. Basically the window, in which
the dma pointer may jitter. I don't think its necessary to play with this anymore. 
.TP
\fB\-t \fI target_delay\fR  
.br
The delay alsa_io should try to approach. Same as for max_diff. It will be setup based on \-p and \-n
which is generally sufficient.
.TP
\fB\-s \fI smooth_array_size\fR  
.br
This parameter controls the size of the array used for smoothing the delay measurement. Its default is 256.
If you use a pretty low period size, you can lower the CPU usage a bit by decreasing this parameter.
However most CPU time is spent in the resampling so this will not be much.
.TP
\fB\-C \fI P Control Clamp\fR  
.br
If you have a PCI card, then the default value (15) of this parameter is too high for \-p64 \-n2... Setting it to 5 should fix that.
Be aware that setting this parameter too low, lets the hf noise on the delay measurement come through onto the resamplerate, so this
might degrade the quality of the output. (but its a threshold value, and it has been chosen, to mask the noise of a USB card,
which has an amplitude which is 50 times higher than that of a PCI card, so 5 wont loose you any quality on a PCI card)

.SH AUTHOR
Torben Hohn

