On Thu, 25 Jan 2007, Spencer Salazar wrote:
OSC in ChucK, as in most other OSC implementations, uses UDP as its transport protocol, which basically means that one's OSC messages sent from ChucK are not guaranteed to ever arrive at their destination, nor are they guaranteed to arrive in order, nor are they guaranteed to arrive only once. Under heavy load it is very likely that the network will drop packets. Believe it or not this is actually desirable for many computer audio applications, as the latency overhead of a reliable transport protocol like TCP is often too great.
If timing is critical, I wouldn't recommend TCP. I foold around a bit with using TCP to determine ensemble (yay plOrK!) timing, and the variance was too much. UDP worked and I didn't notice as great a packet loss as I had expected, although 1) it was a 'closed' network, and 2) my packet traffic wasn't high. If you need to have cake and eat it too, then you can probably use TCP but you would need to imbed some kind of time-stamping to allow you to compensate for late arrivals, or use UDP with sequence numbers to compensate for dropped packets. This would assume that you put some timing 'intelligence' on the receiver end so that it can continue when things get messed up. brad http://music.columbia.edu/~brad