> >RTP timestamps are used for this. > > Sure, it may be used for this but it isn't: MIDI events are played at reception time. In MWPP for example, the timestamp is only used to determine wether a packet is too late or not.
oh, well it should be used for that, doesn't need to be in the protocol probably. as long as there is a timestamp the receiving end can use it to avoid jitter. > >I think a protocol for realtime MIDI over UDP will always have significant > >protocol overhead, I > >don't see this as a problem however. > > Considering a 44 bytes overhead (IP + UDP) + the 4 DMIDI header bytes intended to address a specific node and device, sending a full MIDI data flow (about 1000 3-bytes events per second) requires nearly 400 kbs when the MIDI rate is 31.25 kbs. It's not a problem as long as the corresponding bandwith is available to you. But if you plan to address different devices on the same node (for example using a multiport interface), you should be able to provide each device with an equivalent full MIDI data flow and then the problem seriously increases with the number of devices. normally the full midi bandwidth isn't used except when doing a sysex dump. if events are to be scheduled at exactly the same time they could probably be in the same packet. if not then the RTP timestamp can not be used. when transmitting realtime one doesn't know the events ahead of time so they cannot be combined anyway. for very low bandwidth links compression could be used on top of the protocol. --martijn
