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

Exactly, the user may already have PTP/802.1as running between systems for a common clock... On Jul 24, 2014 3:23 AM, "John Rigg" <ladev7(a)jrigg.co.uk> wrote: _______________________________________________ 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 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