[LAD] [LAU] Open Source Audio Interface

Len Ovens len at ovenwerks.net
Thu Sep 11 22:25:40 UTC 2014

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

More information about the Linux-audio-dev mailing list