On Thu, Jul 24, 2014 at 01:35:20AM +0200, Robin Gareus wrote: > I'm curious why you've made a standalone client out of this, rather than > fixing netjack. Is there any chance that this could become an internal > client (required for forwarding jack-transport)?
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. > What is the use-case of directly resampling for network-transmission? > Are you running two jackd's at different sample-rates? You need resampling even if the sample rates are equal, unless the interconnected system have a common word clock. > i And if not, how does that differ from using netjack and > resampling locally with zita-ajbridge? 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. > Could it be used to bridge two jackd's on localhost with different SR? 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. > Why is it limited to 64 channels only? 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. > Are there any plan to add support for jack-midi ports? 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. > Does it set jack port-latencies properly (after resampling)? 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
