For UDP broadcast gurus: Problems achieving high-bandwidth audio UDP broadcast over WiFi (802.11N and 802.11G)

Question

Hi,

I'm attempting to send multichannel audio over WiFi from one server to multiple client computers using UDP broadcast on a private network.

I'm using software called Pure Data, with a UDP broadcast tool called netsend~ and netreceive~. The code is here: http://www.remu.fr/sound-delta/netsend~/

To cut a long story short, I'm able to achieve sending 9 channels to one client computer in a point-to-point network, but when I try to do broadcast to 2 clients (haven't yet tried more), I get no sound. I can compress the audio and send 4 channels compressed (about 10% size of uncompressed) over UDP broadcast to 2 clients successfully. Or I can send 1 channel over UDP broadcast to 2 clients, with some glitches.

The WiFi router is a Linksys WRT300N. All computers are running Windows XP. The IP addresses are 192.168.1.x, with subnet mask 255.255.255.0 and the subnet broadcast address: 192.168.1.255.

I'm curious - what happens to UDP broadcast packets in the router? If I have a subnet mask of 255.255.255.0, then does the router make 254 packets for every packet sent ot the broadcast address?

My WiFi bandwidth is at least 100Mbps, but I can't seem to send audio of more than around 10Mbps over UDP broadcast to multiple clients.

What's stopping me from sending audio up to the bandwidth limit of the WiFi?

any suggestions for socket code modifications, network setups, router setups, subnet modifications... all very much appreciated!

thanks Nick

Answer 1

I'm curious - what happens to UDP broadcast packets in the router? If I have a subnet mask of 255.255.255.0, then does the router make 254 packets for every packet sent ot the broadcast address?

No the "router" doesn't make 254 individual packets. Furthermore, I suspect the protocol leverages "multicast" addresses rather than using a "broadcast" address.

Since broadcast/multicast traffic can easily be misused, there are many networking equipment that limit/block by default such traffic. Of course, some essential protocols (e.g. ARP, DHCP) rely on broadcast/multicast addresses to function and won't be blocked by default.

Hence, it might be a good thing to check for multicast/broadcast control knobs on your router.

Answer 2

New information: the system is definitely using broadcast, not multicast.

Also, I can successfully stream 4 channels of uncompressed audio (2.8Mbps) on a wired (cat5) connection over the same UDP broadcast setup.
When I switch to 802.11N (connection speed reaching between 200Mbps - 300Mbps), I cannot get an unbroken stream of 4 channels on UDP broadcast to 2 receivers. But if I then do point-to-point streaming (to an individual IP on the same receiver machines), still on the same WiFi connection, I can get a clean 4 channel stream (2.8Mbps).

So, it seems like somehow there is extra bandwidth overhead for UDP broadcast in comparison to a UDP direct connection. This extra overhead makes WiFi unreliable as a transport, although a wired connection will still work.

Why is broadcast on WiFi so poor, and what can I do to improve it?

Answer 3

Are all parties connected via WiFi or is the sender using a wired connection to the Access Point? Broadcast data will be transmitted as unicast data from a station to an access point and the access point will then retransmit the data as broadcast/multicast traffic so it will use twice the on-air bandwidth compared to when the sender sits on the wired side of the AP.

When sending a unicast frame the AP will wait for an ACK from the receiving station and it will retransmit the frame until the ACK arrives (or it times out). Broadcast/multicast frames are not ACKed and therefore not retransmitted. If you have a busy/noisy radio environment this will cause the likelyhood of dropped packets to increase, potentially a lot, for multicast traffic compared to unicast traffic. In an audio application this could certainly be audible.

Also, IIRC, broadcast/multicast traffic does not use the RTS/CTS procedure for reserving the media which exarbates the dropped packets problem.

It could actually be the case that multiple unicast streams work better than a single multicast stream under less-than-ideal radio conditions given that the aggregated bandwidth is high enough.

If you can I would suggest that you use wireshark to sniff the WiFi traffic and take a look at the destination address in the 802.11 header. Then you can verify if the packets are actually broadcast or not over the air.