Re: [LAU] Audio over WIFI

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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user