21 Jan
2015
21 Jan
'15
4:02 p.m.
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
23 Jan
23 Jan
2:39 a.m.
New subject: 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
3621
days inactive
3623
days old
linux-audio-user@lists.linuxaudio.org
1 comments
2 participants
participants (2)
-
Len Ovens -
Leonardo Gabrielli