John Lazzaro wrote:
gives up and throws away a packet. But, its very rare -- 0.1% or less, if I had to put a number on it.
But if that 0.1% was a NoteOff sent to an Hammond organ patch, you care :-). Thus, the recovery journal technology in RTP MIDI.
While I agree that a missed note-off is bad, I think in a non saturated/broken LAN, packet losses are so rare that it does not even pay off to do retransmission. Especially for low latency audio, for midi it might be ok to resend the note-off so that you don't run into hanging notes problems, but for low latency audio retransmission would come too late.
Anyway just a few numbers:
4 PC LAN.
cheap 10/100 d-link switch
moderate surfing/ download activity.
ping -f between hosts run for a few hours.
no packet losses. this means millions of packets exchanged.
I think your 0.1% figure is a few orders of magnitude too high
(in a non congested network). I think you can easily
divide it by 100000 if not more.
As said only a fool would run real time audio/midi on a congested/broken LAN.
So I still state that realtime audio/midi over UDP on a LAN is perfectly
reliable, given that you use a switched network and non broken equipement.
It's just pretending to send 200 midi tracks over a single serial midi cable
(I know it's limited to 16 channels, but the other congestion possibility could be trying
to send 16 tracks with very dense midi event streams).
Firewire/mlan etc is nice because of guaranteed bandwidth etc but ethernet can do it too.
(good switches support QoS)
cheers, Benno http://www.linuxsampler.org
