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
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
