23 Dec
2009
23 Dec
'09
8:33 p.m.
Hi,
On Wednesday 23 December 2009 23:52:46 Patrick Shirkey wrote:
On 12/23/2009 08:08 PM, Arnold Krille wrote:
No, the problem is one or two layers deeper in the stack. We are talking wifi
here. No matter if there is only two devices on that network or a secure
connection, its still wireless transmission over radio frequencies in the 2GHz
range. Which is per se much more affected by any disturbance then a dedicated
cable is. Every mobile phone, every blue-tooth device, every neighbours
network, every iron in your ceiling will influence this. And not only with a
constant background-noise in your frequency range, but also with momentary
scrambling and such stuff. So in the layers you can not (easily) control by
software there is already lots of resending and rescheduling of packets. And
all these introduce uncertainties and latencies you don't want in your audio
transmission. Unless you can do with 100ms latency and more...
There is no way to make it work with guaranteed
low latency. You need
somewhat low latencies to play the keyboard to other music. And you need
it guaranteed unless you always record xruns and gaps as part of your
musical experience...
And even then its wireless and using a frequency-range used by almost all
other people around you. Just count the wireless networks in your flat
provided you live in a flat with other people living
upstairs/downstairs/next to you. And then try to get a fast,
non-interrupted stream (latency about 20ms or shorter for real playing).
So the
issue is with other streams being picked up by the receiver which
affects latency by increasing collisions?
Would this still be a problem on a secured connection? Surely the
receiver would ignore all data that is not being transmitted over the
secured access point? Does anyone have an idea of how to work out the actual
latency for a
wifi packet at 300Mb/s?
The data-rate is not important. What is important is the struggle you do to
get a payload packet out and the reception acknowledged. Wifi is very versatile
and allows usage (almost) everywhere. But you pay a high price in
predictability and latency.
Heck, even the wireless microphones struggle with problems and these "just"
send some analogue data. While digital is simpler in that its only zero or
one, its actually lots more complex on getting data out reliably.
If we are talking about a studio setup with devices no
further than 2
meters distance from each other that should aloow sub 20ms send/receive.
The bottle neck appears to be the chip and the code that manages the
transmit/receive process.
No, the bottle-neck is your neighbours accessing google and facebook via wifi
disturbing your signal momentarily producing gaps and xruns. And the only way
around it is using an area where there are no neighbours.
Once the stream is stable and reliable, it will easily go below 20ms latency.
But getting the stream to be reliable is already complicated with things like
firewire (which has isochronous channels for exactly this purpose) and its more
complicated with usb (which has a master telling the clients when to send
bigger payloads to not disturb the other bus-members). Ask the jack-over-udp
guys how difficult it is to create such stream reliably over tcp-ip network. And
they take lost packets into account (which means an xrun) and advise you to
use it on dedicated networks if you want more the the immediate experience...
If jacknet over wifi fills your needs, use it. But if it doesn't don't blame it
on its developers, blame it on the underlying network (-technology) used.
Have fun,
Arnold