[LAD] Beta testers required...

[Fons Adriaensen]

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)