zita-ajbridge 0.8.4     (05/04/2020)
-------------------

* Fixed 100% CPU on sound card disconnect.
  

zita-ajbridge 0.8.2     (25/08/2018)
-------------------

* Maintenance release.
  

zita-ajbridge 0.8.0     (28/04/2018)
-------------------

* Replaced jack time routines by those used in
  zita-njbridge (timers.h).
  

zita-ajbridge 0.7.0     (15/09/2016)
-------------------

* Fixed bug in timing of Alsa stream. This should put
  an end to those repeating 'Excessive timing errors'.
  Thanks to Tomasz Kasprzak for the bug report and fix.

* Fixed auto selection of resampling filter lenght.


zita-ajbridge 0.6.0     (22/08/2015)
-------------------

* Automatic selection of resampling filter lenght
  based on sample rates rather than fixed default.

* -S option disables resampling, this requires
  word-clock sync of devices.

* Code cleanup and bugfixes.


zita-ajbridge 0.4.0     (17/09/2013)
-------------------

* The 'JackPortIsTerminal' and 'JackPortIsPhysical'
  flags are set on the Jack ports.

* The correct latency value is set on the Jack ports. 
  
  This is the latency resulting from buffering and
  resampling. It does not include any additional
  latency due to processing by the sound card, e.g.
  from anti-alias filters. This can be added using
  the -I (for a2j) and -O (for j2a) options, in the
  same way as for Jack's ALSA backend.

The latency values can be tested as follows, using
jack_iodelay which comes with Jack. The value we want
to know is the 'excess' round-trip latency - this is
the measured value minus the port latencies. You could
also use jack_delay (on my website) with the -E option.

First measure the latency of your sound card in the
normal way. Then, run Jack with the dummy backend,
run zita-a2j and zita-j2a on the same soundcard with
the same parameters as previously used for Jack's
ALSA backend. Again measure the excess round-trip
latency. It should be the same as in the first
measurement.


zita-ajbridge 0.2.0
-------------------

This package provides two applications, zita-a2j and zita-j2a.
They allow to use an ALSA device as a Jack client, to provide
additional capture (a2j) or playback (j2a) channels. 
Functionally these are equivalent to the alsa_in and alsa_out
clients that come with Jack, but they provide much better audio
quality. The resampling ratio will typically be stable within
1 PPM and change only very smoothly. Delay will be stable as
well even under worse case conditions, e.g. the Jack client
running near the end of the cycle.

The theory of operation and internals of these apps are the
subject of a paper to be presented at LAC 2012. 

The alsa device should be a 'hw:' one, i.e. direct access to a
soundcard and not an ALSA 'plug' device. A well-working Jack
system is assumed, running in real-time mode.

The sample rate can be the same as Jack's one, or different.
Minimum delay is obtained by running the alsa device at a lower
period size than Jack. This can be done safely as the alsa thread
will run at a higher priority, and apart from copying to/from an
internal buffer no work is done there. There are no restrictions
on the product of period_size and number_of_periods as there are
for alsa_in and alsa_out.

Both apps will optionally print some information four times per
second. The first number is the average loop error over the last
quarter second, in samples. It should be reduced to small randowm
values close to zero after 15 seconds or so. The second is the
dynamic correction factor of the nominal resampling ratio. This
should converge to a value close to one and not move much.
You may observe small variations in these numbers when Jack apps
are started or stopped. This is normal. Anything else isn't -
please report. 

The same -v option will enable detailed error reporting from
the ALSA interface, or if all is OK print a summary of the ALSA
device configuration.

The -L option forces the ALSA device to 2 channels and 16-bit
sample format. This can be required when using the ALSA loop
device if the other side (e.g. mplayer) does not support more
channels or a floating point sample format. This will fail on
real hw: devices as these can be opened in mmap mode only with
their real number of channels.

When starting, and in case of major trouble, you will see the
'Starting synchronisation' message. This can happen if there is
a timeout on the Jack server, e.g. a client crashed or terminated
in a dirty way. Jack1 will skip one or more cycles when new apps
are started, or when a large number of port connections is done
in a short time.  his may interrupt the audio signal, but should
otherwise not have any ill consequences nor require a restart.

Both apps will suspend operation while Jack is in 'freewheeling'
mode. When using Jack1, returning from freewheeling to normal
mode may generate large timing errors, the result of Jack's DLL
not being re-initialised properly. Both apps will wait for 15
seconds before restarting if that happens. Patches to Jack1 have
been submitted, so this problem should go away in the future.

-- 
FA






