Re: [LAD] 802.11n sound card

Hi,

On Wednesday 23 December 2009 23:52:46 Patrick Shirkey wrote:
> On 12/23/2009 08:08 PM, Arnold Krille wrote:
> > 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?

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...

> 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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev