Forum

Howto obtainig low(est) latency over lan

vvvv beta question
#1

im planning an installation of multiple computers running vvvv in a LAN that all do different things and im looking for a good data rate for ‘real time’ messages: audio fft, kinect data, midi keys.
i am currently not planning to have a boygroup setup.

  • what transmission tehnique would you recommend ?
  • are there practical tips on improving actual data transmission ?
  • there is one special case where one computer would not run v4, but ableton. is there an established way to send midi data to ableton over lan ?

one answer i found was using dmx artnet send. before diving into it, does it make sense to have a boygroup only for transmitting small but fast strings ?

thanks
ggml

#2

i started off using the dmx artnet approach, but changed that recently. there were a bunch of reasons for that, the main ones were that the node did not work well with /allowmultiple, and that all values had to be between 0 and 1 and were quantized with only 256 steps.

now i use a simple UDP node and make sure that the packet size stays below 1492. especially in combination with this this approach has hardly any overhead.

mind you, the boygrouping is still important, but the actual realtime data is sent separately. this way i can use as many ports as needed (if there is more data then 1492 byte), without cluttering the actual boygroup.

for the midi transmission over Lan i found rtpMidi most useful, it brings Apple’s Bonjour protocol for Midi to the PC. There are a bunch of other apps that do something like this, but most cost money.

for ableton, have a look at LivvvveOSC

#3

hi ggml, yes rtmidi is a real good solution.

i would recommand you to use artnet, as there is many things you can do with 512 values of 256 steps.
if you have some floatting points, a second udp sender will be great for your own OSC encoding orders.

If you are using wifi, use ad-hoc mode. very important !

#4

thank you for the information. tbmc, here is what i plan:

2 computers sending out kinect data (a 3d vector) to a ‘server’
‘server’ sends out dmx over usb dongle to some pars (smth like 3x72 values)
‘server’ sends midi data to a fourth computer running ableton

my concerns for communication are:

  • the kinect 3d vector being delayed over udp, i remember udp lagging a bit, but then again i wasnt aware of the packet size limit.
  • ‘server’ being overload with recieving 2 udp ports and sending out dmx and midi

regarding sebllll’s plugins: am i supposed to use ValueAsByte to weigh the packets ?

regarding midi: how fast is midi compared to udp/artnet ? i picture it being pretty realtime between 2 musical instruments… will i be getting extra delays using it in a lan?

ggml

#5

midi 8 bits in LAN protocol will be shorter, as its sending only one signal ( CC Type Vel ) at once.

Artnet is usually 538 bytes length

" i remember udp lagging a bit" > what is lagging is Firewalls, and encryption/decryption process on large amount of datas. especially in OSC with the keyword things. Question is : how many values will you send from your kinect ?

If you can work with kinnect on a summerized number of vertices you should merely think about artnet using 16 bits modules from Kalle and some smoothing with damper or IIR, and mapping. See Uncle Kalles DMX 16 bits modules.
Use 2 dmx channel to work in 16 bits value with artnet:
first channel will increase of 1 step (on 255) when channel 2 as raised 255 value. So you may have things more smoother than midi .
See?
It will make you 256 points per art-net universe with an acceptable resolution for moves and precision. You can work with 2 or 3 or 4 universes ;-) the limitation by splitting vertices in universe will be compensed by number of ethernet adpatators

There is also possibility to work in midi 10bits, but i dont remember if rtMidi is handling it.

#6

i’m currently sending 3 full kinect skeleton data packs (xyz) to one server and have no problem with packet size and latency.

converting floats to bytedata, which the plugin on sebls git is doing, is fine, if you don’t need to structure your data.
i’m using osc which is almost as short as direct conversion to byte if you encode a whole spread into one osc address (e.g. for a spread of 512 values you need following type tag: ‘ffff… (512times)’ not a spread!)

© vvvv group