12 Sep
2014
12 Sep
'14
12:27 a.m.
On Thu, 11 Sep 2014, Fons Adriaensen wrote:
If any audio HW would transmit the packet format
expected by
zita-n2j (which is fairly simple), it would just work. You
Yes it does.
could even have many such interfaces connected at the
same
time (all it takes is a network switch) and they wouldn't
need a common clock.
Ok, Could I have two mics, one left and one right each going through two
of these interfaces without a common clock and sound right? Or even both
mono but fairly close to each other? Assuming all our audio channels are
in the same packet stream would resampling still allow them to at least be
syncronised to each other?
Switch: What kind of latency is required? Packet A from AI A would then be
delayed by packet B from AI B at the switch. The switch does not know the
difference between audio and data, so common data may delay it further. At
least the switch should prevent collisions though.
And of course it is possible to create a Jack backend
that
accepts the same format but without the resampling (that's
in the pipeline actually).
Ah, I may wait then. This seems to answer my biggest doubt.
Re. the format used by njbridge: for IPv4 the IP and
UDP
headers together take 28 bytes. That is less than 2 percent
of 1500, and is a small price for having packets that can be
handled by switches and routers. There is really no point in
Raw ethernet packages should have no problem with a switch. I would
question the use of a router, but already installed infrastructure might
have it sitting there anyway. For our use case (an audio interface) there
would be no router. Possibly a switch may be used if the AI was far enough
from the host.
trying to reduce that sort of overhead. The njbridge
format
itself adds a 20 byte header to sample packets. This data is
used to identify the packet, to improve the timing and handle
skipped cycles, xruns, lost packets and the like. All together
the overhead is less than 3.5%.
To be honest the only thing that has really been a stopper for njbridge in
this application has been the resampling. Making it work as well when sync
is available would fix that.
reducing overhead only really effects channel count and then only on a
100m link. I personally can't imagine 32 plus channels (not ascribing any
maximum channel count to njbridge, I don't know) for anything I
would do... and where I can imagine lots of channels I also see lots of
money where whatever I need could just be bought, open or no. I was merely
thinking expandability.
Using 1500 byte packets would seem to me to be adding unneeded latency, I
would rather pay the price in overhead I think. At a low channel count it
would take a number of sample times to fill 1500 bytes. (I should be more
specific, I am basing all my calc on 48k and a 100m link where the 1500
byte packet would already be ~6 samples long) Assuming the same 32 bits
per sample/channel, 8 channels is only 32 bytes per sample. we would be
looking at around 45 samples worth of time to fill the buffer and then add
6 more samples assuming there is already some network data in the que..
about 1ms. Perhaps that is not too bad then. Higher channel counts would
have lower possible latency. I really can't speak for the cpu time
involved in sending/receiving (making/breaking packets) but expect it
could be minimal.
--
Len Ovens
www.ovenwerks.net