[LAD] 802.11n sound card

[Arnold Krille]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20091224/76dc43a9/attachment.pgp>