Anyone interested in beta-testing this please let me know. Zita-njbridge ------------- Command line Jack clients to transmit full quality multichannel audio over a local IP network, with adaptive resampling at the receiver. Main features: * One-to-one (UDP) or one-to-many (multicast). * Sender and receiver(s) can each have their own sample rate and period size. * Up to 64 channels, 16 or 24 bit or float samples. * Receiver(s) can select any combination of channels. * Low latency, optional additional buffering. * High quality jitter-free resampling. * Graceful handling of xruns, skipped cycles, lost packets and freewheeling. * IP6 fully supported. * Requires zita-resampler, no other dependencies. Note that this version is meant for use on a *local* network. It may work or not on the wider internet if receiver(s) are configured for additional buffering, and if you are lucky. The current code will replace any gaps in the audio stream by silence, and does not attempt to re-insert packets that arrive out of order. You will need a fairly recent Jack version, as the code uses jack_get_cycle_times() and no fallback for that is provided. Ciao,

Anyone interested in beta-testing this please let me know. Zita-njbridge ------------- Command line Jack clients to transmit full quality multichannel audio over a local IP network, with adaptive resampling at the receiver. Main features: * One-to-one (UDP) or one-to-many (multicast). * Sender and receiver(s) can each have their own sample rate and period size. * Up to 64 channels, 16 or 24 bit or float samples. * Receiver(s) can select any combination of channels. * Low latency, optional additional buffering. * High quality jitter-free resampling. * Graceful handling of xruns, skipped cycles, lost packets and freewheeling. * IP6 fully supported. * Requires zita-resampler, no other dependencies.

You need resampling even if the sample rates are equal, unless the interconnected system have a common word clock.

On Thu, Jul 24, 2014 at 01:35:20AM +0200, Robin Gareus wrote: Nothing would have remained of netjack. And it's a different concept anway. Zita-njbridge replaces jacktrip, not netjack. Zita-njbridge is designed to interconnect Jack systems that remain fully independent, each of them can be used locally in the normal way. This is an explicit design goal. There is no master/slave relation between sender and receiver(s). For example, stopping a sender doesn't affect the receiver(s) in any way apart from the signals reverting to silence until the sender (or a different one) comes back. You need resampling even if the sample rates are equal, unless the interconnected system have a common word clock. If you have just two systems you could achieve more or less the same by using netjack and zita-ajbridge on the 'slave' system. But you'd have a master/slave relationship which does not exist when using zita-njbridge. Yes. But that would be more efficient ways to do this, e.g. in a single application that would re-use the jack code but not pass via the network, not even loopback. This is planned. Should be enough in most cases. Neatly replaces a MADI link. You could run more than one instance if you need more, and there may be advantages doing that, they could uses different NICs for example. Would be possible, there are still 254 unused packet types. But there are no plans for that ATM. You'd also need to define what exactly is expected when transporting MIDI. Should it have the same latency as the audio ? Or the minimum possible ? Plus, is there any need to integrate this ? You can send MIDI via OSC for example. I'd prefer to use separate apps for that rather than bloat njbridge. The current version does not set latencies. One reason for this is that it's not at all clear what these should be in the first place. The same signal can be sent to many receivers, each of those can have its own buffer size (and hence latency), so what is the output latency from the POV of the sender ? And remember that all interconnect systems are meant to remain independent of each other, the sender doesn't even know who is listening in the multicast case, and there is no return channel. Future versions may include metadata to describe the transmitted signals (this is why there is a separate 'descriptor' packet), this metadata could include latency values. But that would be input latency from the receiver's POV only. -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev

On Thu, Jul 24, 2014 at 08:42:48AM +0000, Fons Adriaensen wrote: Can the resampling be switched off in cases where a common word clock is available? John _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev(a)lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev

On Thu, Jul 24, 2014 at 08:42:48AM +0000, Fons Adriaensen wrote: Can the resampling be switched off in cases where a common word clock is available?