Hi,

over at forum.gbadev.com, some people are discussing Wifi as possible carrier for MIDI data. The results so far are as follows: A TCP connection has barely enough performance to be usable; UDP would be great but suffers badly from packet loss, even if on the same LAN. (As an example, ping yields about 11% packet loss, which kills music applications.)

The question is now: Is this a fact of life for the DS, or is it possible to improve that number by DSWifi tweaks? Anyone know?

Thanks a lot in advance,
Björn

Hmm?

Midi 1.0-HW Datarate is 31.25kBits/sec. Even if the lib would be extreme timewasting and reducing the wifi speed 50x, there should still be enough place to stream your midi data.

A custom retransmitting UDP protocol should be sufficient for this sort of thing, and TCP will do a pretty good job too - for local connections you should be able to get a minimum of 2 to 3 times the performance necessary, even with a lossy connection. That being said, 11% packet loss isn't typical in my experience, and if it does occur, it's likely an issue with signal strength and distance between the DS and router/AP
(actual wifi speed is approximately 2mbit, I've achieved transfer rates through tcp of roughly 80kbyte/sec - and this will improve with future libraries)

-Stephen

OK, so it's probably my connection that's at fault; I'll investigate that.

As far as the performance is concerned: Yes, the bandwidth of the 2Mbps link is more than enough to accomodate MIDI data. Unfortunately for MIDI, latency is just as important as bandwidth, if not more. A rule of thumb is that you will notice if there is more than a ~30ms delay between your keyboard and the sound generator. Even if just one in a hundred notes comes significantly later, it will break the flow of playing. On a lossy connection (mine here, specifically), I've seen lag times of up to a second fairly often. That was the reason for my question.

If you're worried about latency, you should certainly use a custom realtime UDP protocol - you can be guaranteed latency under 30ms for small messages unless more than x number of retries have to be made (depending on the size of the packet, and other factors) Data is sent at 2mbit, which is 2 million bits per second exactly; If you'd like exact timing information, see the following data:
---
2mbit is exactly 2 million bits per second, or half a microsecond per bit.
The following elements are present in a UDP packet:
(802.11 phy overhead:)
96 bits plcp preamble
32 bits plcp header
(total of 128 bits / 16 bytes)
(802.11 protocol overhead:)
24 bytes 802.11 header
4 bytes extra (for WEP IV)
(now, actual data:)
8 bytes LLC header
20 bytes IP header
8 bytes UDP header
x bytes data (your data goes here)
4 bytes 802.11 CRC32

Soooo, adding all that together gets us:
84+x bytes (where x is the number of bytes in your packet)
which is
672+8x bits (or 336 + 4x microseconds)
as you can see, 802.11 is more than capable of delivering a message within 30ms, but the question is more one of whether the message gets received

TCP is presently set up for reliable operation over long distances, so it's really not ideal for this sort of application; though this is one area I plan to improve in the future.

Anyway, good luck

-Stephen