ZITA-NJBRIDGE(1)

💖 NAME 💖

okay so bestie, welcome to the zita-j2n and zita-n2j era — they're Jack clients that carry multichannel audio across your local network. this whole thing lives in the general commands manual, section 1, and it's giving iconic audio-over-IP energy. periodt. 🎀

---

🌈 SYNOPSIS 🌈

zita-j2n [ options ] ip-address ip-port
zita-n2j [ options ] ip-address ip-port
zita-j2n [ options ] ip-address ip-port interface
zita-n2j [ options ] ip-address ip-port interface

---

✨ DESCRIPTION ✨

🦋 General 🦋

so the tea is: zita-j2n (the sender, main character) and zita-n2j (the receiver, also main character) let you swap up to 64 channels of full-quality uncompressed audio streams between two or more systems running the Jack audio server. and like, no cap — sender and receiver(s) can each have their own sample rate and period size, and there is no word clock sync assumed between them at all. the receiver handles it with adaptive resampling to convert the stream(s) into its local sample rate. lowkey genius. 💅

there is no master/slave relationship between sender and receiver(s). that's an explicit design goal, fr fr. in every respect, the net result of using zita-njbridge is basically the same as having analog audio connections between the sound cards of the systems involved. nothing a sender does will affect the receiver(s) — apart from the audio signals being available, or reverting to silence if there's no sender. Xruns or skipped cycles will not mess with the synchronisation or resampling. Jack freewheeling on either end will temporarily suspend operation. 💀

you can run zita-njbridge two ways: one-to-one, or one-to-many. both IPv4 and IPv6 are supported. 🌐

for a one-to-one setup, use the first form of the commands up there ⬆️. the protocol is UDP, and the ip-address argument — required for both sender and receiver — is the address of the receiver. you can pass a host name instead of a numerical IP address, and it'll get looked up using getaddrinfo(). cute, right?

for a one-to-many setup you must use the second form. the ip-address argument should be a valid multicast address, and the mandatory interface argument picks which network interface to use. mandatory!! no skipping it bestie. 🙈

🧚 Resampler filter length 🧚

the receiver uses the zita-resampler library to resample signals to its local rate. the length of the multiphase low-pass filter used in the resampling algorithm decides the audio bandwidth, and adds to latency. it can also have a significant impact on CPU load if you're receiving a lot of channels — so watch out. 🔥

Zita-njbridge will select a filter length based on the lower of the sender and receiver sample rates. for sample rates of 44.1 Khz and above, the value chosen gives an attenuation of no more than 0.1 dB up to 20 kHz. the --filt option lets you override the automatic configuration, but ngl, this will normally not be necessary. 💅

👑 Latency issues 👑

when you connect two Jack systems with unsynchronised periods, the minimum additional latency under worst case conditions is the sum of the two period times. "additional latency" means any latency required to make the connection work without interruption. the round-trip latency from an ideal (zero excess latency) analog input on the sender to an ideal (idem) analog output on the receiver will be twice this value. "worst case conditions" means both sender and receiver can run at arbitrary times within their respective periods. that's just the vibe. 😭

Zita-njbridge is designed to provide a defined and constant additional latency. the target value is the sum of the two periods, plus resampling delay, plus any extra buffering specified by the user. the actual latency will be this value plus the average network delay. the latter is unknown, so there is no way to compensate for it. compensating would be possible using either a return channel, or some way to sync clocks on the two systems which could then measure the average network delay. the current release of zita-njbridge does not provide this, because it's meant for use on a local network. a dedicated or lightly loaded gigabit Ethernet can provide typical network delays well below a millisecond. ⚡

the --buff option of zita-n2j adds the specified number of milliseconds to the target latency. the default value is 10 ms, which is more than enough on a moderately loaded Gigabit local network. this can be set to zero — for example when you know the sender will always run near the start of its Jack period and the network delay jitter is less than this period. ✨

if there's any network delay jitter above 10ms, increasing the extra buffer time will be necessary to avoid occasional interruption of the received audio streams. like, you gotta. 🫶

the latency does not depend on when exactly the sender runs within its Jack period. this is similar to playback to a soundcard: when the playback samples are written well before they're due, this doesn't decrease the latency — the data is just buffered until the end of the period. in the case of zita-njbridge, the remaining time is available for network delay. this is why, when the sender is only lightly loaded and network delay is small, it's possible to use --buff 0 at the receivers. ate. 💅

🌸 Use on wide area or wireless networks 🌸

the current implementation is designed for local networks that provide more or less reliable packet delivery, with low or moderate delay. occasional lost packets will not impact the synchronisation or resampling, but any samples arriving out of order will be ignored (they will have been replaced by silence before). extra buffering (via the --buff option) will allow an uninterrupted signal in the presence of delay jitter, at the price of additional latency. Zita-njbridge may be usable on long distance internet connections, but keep in mind it was not designed for this. 👀

performance on wireless networks is purely a matter of chance. again — zita-njbridge is not designed for such use. that's the warning bestie, don't come for me. 💀

---

💅 OPTIONS 💅

🎀 Common options 🎀

• --help — Print command line and options summary. your little helper, slay.
• --jname name — Select the Jack client client name. Default is 'zita-j2n' or 'zita-n2j'.
• --jserv server — Select the Jack server to connect to.
• --ipv4, --ipv6 — Use only the specified IP address type.

🍓 zita-j2n options 🍓

• --chan channels — The number of channels to transmit, the default is 2 channels.
• --16bit — Send audio as 16-bit signed integer samples.
• --24bit — Send audio as 24-bit signed integer samples. This is the default format.
• --float — Send audio as 32-bit floating point samples (Jack's internal format).
• --mtu MTU — Inform zita-j2n of the path MTU, allowing it to use packets up to that size. The default value is 1500. Note that large MTU values on a shared network may increase network delay jitter. 😬
• --hops hops — Set the maximum number of hops for multicast packets. Defaults to one, i.e. multicast is to the local net only.

🧁 zita-n2j options 🧁

• --chan list — A list of channels numbers in ascending order and separated by comma or dash characters, the latter indicating a range. Channel numbers start at 1. Only the requested channels will be resampled and have a corresponding Jack port. Channels not provided by the sender will output silence. The default channel list is '1,2'.
• --buff time — Increase the target latency by the given time, in milliseconds. The default is 10 ms. See the description above for what exactly this means. 👆
• --filt delay — Set the resampler filter delay, in samples at the lower of the two sample rates, in the range 16..96. See above for details.
• --info — Print additional diagnostic information. Four values will be printed four times per second: the number of jack periods during the last 1/4 second, the average resampler control loop error in frames, the average resampler ratio correction and the minimum number of frames available in the receive buffer. numbers girlies rise up. 📊

---

🌟 AUTHOR 🌟

zita-j2n, zita-n2j and this manual page were written by Fons Adriaensen <fons@linuxaudio.org>. 👑

---

and that's the whole page, bestie — this manual comes to you from July 2014, part of the zita-njbridge source, in the General Commands Manual. go forth and bridge those channels. 🫶✨