On Wed, 21 Jan 2015, Leonardo Gabrielli wrote:
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
That does not need to be. My 10 year old P4 was running an ice1712 at 48k/16/2 (.66ms) with no xruns. This is not even a RT kernel just lowlatency. It was also running an OS with DE. If it was set up for 48k/16/3, that would be 1ms and provide an AES67 acceptable packet. Remember, that any finished product would not doing most of the things that a desktop or android device does. So now buffer up three of these 1 ms packets into the wireless (more would be ok and may not be noticed by by the net at the other end) This would already have cut the delay by 8ms. There are set top devices out there the size of a thumb for ~$50, so it would not be overly expensive to use one processor just for the wireless and the other for audio or to use a two core device to split the WIFI and audio processing so they don't trip each other up.
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
What speed wifi? One of the things that made AES67 possible is fast ethernet (GB). This determines the turnaround time at a switch (or AP) to forward a packet on. It is completely possible for a packet (1ms of audio) to leave the buffer of one system and be into the buffer of another having gone through some switches as well on such a fast link before the next ms of audio is ready to send.
Some WIFI standards are already over 1gig so this is not impossible. The big difference between wired and wireless is colisions. Wired has no colisions in any one link and across a switch the delay is que length. With wireless a colision means waitng and trying again with no guarantee of success. It is actually more complex than this. It is possible for two pairs (or more) of WIFI ends to move data at the same time if their frequency hopping is far enough out of sync. The only colisions should be systems connected to the same AP. (still not the whole picture but getting closer) This means power/antenna gain does matter. A strong signal will walk over other wifi activity in the area, but with proper antenna setup may still not cause undo interference in the area. (legal power/erp/gain limits must still be followed) A grounded conductive curtain might be used to good effect to cut down interference as well. (might help keep people from using their cell phone in the middle of things as well ;) )
I have seen some very interesting coverage patterns from AM antenna sites to make the best use of power while not interfering with other broadcasters. I have not seen this kind of activity with WIFI at all, it is either omni or directional (yagi). It does not seem reasonable to go to the trouble for each site on a tour but it may be possible to set up something generic that is better than omni anyway.
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
32 samples is not one of the packet sizes to use. The AES67 doc says 6,12,16,48 and 192 are the numbers. Thats why jack/alsa set to 16/3 for 48 makes sense. Notice all of them are multiples of 3.
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.
The OS on a GP unit could do it. The WIFI we have these days I am not so sure of... finding a WIFI unit that does not mess with the audio RT stuff would be the sticking point. We are only talking a few channels, not 128 or more which may help.
I will keep thinking. -- Len Ovens www.ovenwerks.net _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
