Re: [LAD] Beta testers required...

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
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
>

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Jul 24 16:15:01 2014