Hi Fons, that sounds too good to be true!
It is obvious you have made a lot of important thoughts. I totally agree on the conceptual goals (sounds familiar, i've even tried to do about the same with OSC as you might know, without resampling:). I'll be very interested to get it running once available for the public. Great initiative, Cheers Tom On Thu, July 24, 2014 10:42, Fons Adriaensen wrote: > 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 > > _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
