5 Aug
2014
5 Aug
'14
7:08 a.m.
~ Russell
On Aug 4, 2014, at 1:58 PM, Len Ovens
<len(a)ovenwerks.net> wrote:
Just out of curiosity, what kind o data throughput did that create? 100mb links?
Switch and or router in the middle? Just curious to the interaction across the wire.
1024mb/s (GigE hardware is more modern, firmware typically closer to current) vs 100mb
links. The common theory would be that gig 'pipes' only become relevant when data
reaches capacity near or over 100mb. Bit like the 32bit vs 64bit OS argument in some ways.
Perhaps the differences will be negligible in the end game. But it might be the difference
of running that 64/2 link at 32/2... Too!
On Mon, 4 Aug 2014, Fons Adriaensen wrote:
Zita-njbridge-0.1.0 is now available.
Actually 0.1.1 since then.
Zita-j2n and zita-n2j are command line Jack clients to
transmit full quality multichannel audio over a local IP
network, with adaptive resampling by the receiver(s).
This works very well with my limited testing.
In response to the query about studio routing use:
If you can afford the i/o cards this will work fine. The latency can be very low.
I did:
Audio file -> IF out
plus
Audio file (same jack port) -> zita-j2n -> zita-n2j -> IF out (same port as
above)
Jack set to -p64.
There was (of course) some comb filtering but I suspect it was not enough delay to throw
off any musicians if it was used for monitoring. I tried both --buff 0 and the default 10.
The only difference being the frequency of the comb filtering. The only thing to watch is
that the same audio doesn't get mixed with something that has gone through the link.
Or mixing two mics, one local and one remote that share the same acoustic space.
Zita-njbridge does not handle on the fly latency changes in jack, so switching latency
from really low for tracking to higher for mixdown will mean restarting the link(s).
Though the link probably should not be needed for mixing anyway. It wouldn't take much
to create a script that "respawed" the link if it was needed.
--