Thanks Len for the useful feedback.
In such a case, it would not be possible to add a WIFI
that went to AP
then snake then FOH mix then monitor as there would be close to 30ms. The
WIFI would have to be a dirrect input to the FOH mix.
In reality of the 16ms latency I mentioned, 5.3ms are the A/D and 5.3ms are
the D/A (48khz, 2 periods of 128 samples in JACK at both sides). The
remainder approx. 5.3ms is buffering large enough to compensate for the
jittery behavior of network delay. In other words a packet needs reasonably
less than <5.3ms to fly from one end to the other. With an AP things are a
bit more delicate for the only reason that the packet must fly twice, i.e.
the transmitter must get access to the medium ASAP, and then the AP must
get access to the medium ASAP to relay the packet to the recipient. And
they must meet the deadline imposed by the receiver JACK cycle. Medium
access with 802.11 is the biggest issue in my experience. However, with an
AP it won't be 30ms, it will be much lower. Obviously a TDMA mechanism
would be much more useful for the transmission rather than the 802.11 MAC,
but improvements can be done. There is one AES paper from a guy in Finland
who managed to send 8channel audio at 192khz in packets of about 50samples
each, see
http://www.aes.org/e-lib/browse.cfm?elib=16138
I will take a look again at the AES67 minimum requirements, I guess to
reach them a lot to development must be done. Basically the A/D and D/A
must be done with 2 ping-pong buffers of 32 samples at 48khz, and hope that
the network access and transport can be carried on reliably in 1.8ms.
Nothing you could do with a general purpose platform or OS at the moment,
but a good challenge for the future years.
Cheers,
Leonardo