[LAU] Audio over WIFI

[Len Ovens]

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