udp send/receive data loss (pics included)
Dec 11, 2010 at 4:09pm
udp send/receive data loss (pics included)
I have been running some tests on the udp send & receive modules.
system :I am running a fairly quick dual core 3.2ghz 800mhz fsb, XP and I was not torturing the cpu during this test. load was fluttering around 4 percent. so i am unsure why there is missing data?
hope this all makes sense any help on this would be cool. : )
Dec 12, 2010 at 12:04am
I guess it’s due to the weakness of the UDP protocol – it tends to skip messages when they flood your system.
Quote from Wikipedia:
UDP uses a simple transmission model without implicit hand-shaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. UDP assumes that error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time system. If error correction facilities are needed at the network interface level, an application may use the Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for this purpose.
I set up an UDP connection once, between two computers running Max/MSP, and sent messages in regular intervals (using a metro object). I figured if the interval between messages is less than 6 ms it will skip some of the messages.
Have you tried using TCP instead? The drawback of TCP is that it’s a little bit slower, but it always makes sure the packages arrive.
BTW – it’s a really nice thing you’re making! Does it also work with Cubase?
Dec 12, 2010 at 1:48am
you might try [count] instead, it doesn’t have the overhead that [print] does, I don’t think. you can’t see it in real-time, just the results, but it may be that you’re actually getting the values right but the tiny amount of time it takes for [print] to do its thing could be misleading your analysis.
If it really is skipping due to the udp itself, then, well… you got me :/
Dec 12, 2010 at 3:58am
thank you both for your replies.
I have tried (net.tcp.send) and recv objects but the result was just as poor. so this is rather peculiar ! I am just about to reinstall a fresh OS on a more powerful quad machine and see how I go with that as maybe I have a strange conflict going on somewhere? I was wondering perhaps there is a way to assign more resources (memory and cpu) to the udp or tcp protocol?
if all else fails i may just have to place my entire project inside a vst instrument or plugin so there would be no need to use UDP or tcp as all the data and processing resides inside the vst area …or so i think? lol.
I shall endeavour to find a solution and post here later today.
peace : )
Dec 12, 2010 at 6:23am
I have just tried the experiment on my other machine with a fresh OS and max/ nuendo install but the same problem arises.
in brief : I create a simple automation pattern on the sequencer timeline, send that into the vst>udp pluggo plugin i made. that info is then sent and received in maxmsp but when it arrives there is missing data at random moments.
so i tried the TCP variation of the plugin ( mxj net.tcp.send) & recv modules. these are worse. How can this be? One in every few numbers are missing at the receive side of max.
So it really is strange. could it be that the (pp) object inside the plugin that converts the vst data into usable max numbers is unable to cope? could the problem be the plugin? I thought to include a (print) inside the plugin itself, but unfortunately print does not work inside pluggo runtime.
however, there is similar plugin called “oscglue” that converts vst into osc but that has the same issues as mine. jittery ,missing data also unable to specify a single IP so it broadcasts to all on the network. hence i decided to make this pluggo.
maybe this is a scheduling issue? a performance tweak needed inside max?
i am using localhost port 71 for my tests. RME raydat and 9636 and EMU 1616m soundcards have been used during these tests on bios primed/ stable machines. i have very low quality graphics cards @ £25 lol. but i cant see that being the issue?
lost > : /
Dec 12, 2010 at 7:24am
Here are the pluggo plugins (UDP and TCP) and receive patch in a zip. if anyone is interested, it may just be that i’ve forgotten a simple module in the plugin? Pluggo runtime is needed to make it all work. here:
max 5 patch and localhost plugins zip file here on fileden:
i used 4.6.1 to make the plugin, but the receive patch is in max 5 format.
Dec 12, 2010 at 8:09pm
Maybe i’m totally wrong but could you try [jit.qfaker] -> [udpsend ...] so that it force your message to be sended in high-priority thread ?
Dec 13, 2010 at 12:41am
Actually, I think using VST would be a good solution!
Dec 13, 2010 at 6:02pm
hi I thank you all for your support,
I am still testing pluggo and VST, no luck so far, UDP may not be the problem, I shall report when I can be more certain after a few more tests. Needed to reply tonight so you all know I am still tryng to find a way to make this work.
teqy : )
Dec 14, 2010 at 12:12pm
I'm far from better a specialist about these things, so i might be wrong again, but, just wondering : Maybe you have to much udp packets ? What if you group a bit your data before sending it? I was just looking at [aka.datagram] maxhelp ( http://maxobjects.com/?v=objects&id_objet=1937 ) and was looking at the “resizes buffer” option…
Dec 14, 2010 at 4:13pm
hello thanks, i shall try that object out alexandre! : )
***Interesting development **** I have found that UDP is not the only prime suspect for missing data.
I created a (line) loop patch so that the line object created a smooth loop 0 > 100 > 0 > 100 , just like i created a rubberband pattern in nuendo.
first test was inside Max5 only , I routed the line loop to a updsend localhost 71 and received it inside the same max patch and of course it worked perfectly. I printed out the results every digit accounted for. After this I created a Pluggo plugin .dll with the same line loop design, So now this next test i’m sending a loop from within the pluggo nuendo VST > back outside and into Max 5 which again has receiveudp 71 running. and behold, perfect results printed out, every last digit.
so udp is perfectly fine with this small stream of data, as it should be. and pluggo is happy too!
‘Yet’ the problem of missing data still exsists when using rubbberband automation inside vst!!
So could it be the PP object converting rubberband data into usable max data ? Is this the bottleneck? but how can this be a bottleneck with such a simple pattern, with so little information.
Is anyone here running a mac and logic? Most of my tests are on XP and steinberg!
thanks for any ideas help on this : )
Dec 14, 2010 at 5:07pm
(aka.datagram) seems to be mac only, A buffer may be what is needed to solve this puzzle.
Dec 14, 2010 at 6:28pm
I removed the PP object from my pluggo plugin; and instead went for a (plugmidiin)
so (PP) is the problem on my XP VST system. So I am unable to use PP as it causes data loss and confusion. I wish I had an apple mac and logic , to see if it is a flaw in actually the windows externals or windozzie itself.
I used the same vst pattern for both tests, both the PP and the midi outputed the same number of digits per 2 bar loop . (I believe it was 84 numbers every 2 seconds?)not that many at all. So the resolution is the same with the same rubber band pattern ( only the possible range is different) ie 0-127 for midi CC and vst (PP) > max is well …. very deep/wide indeed.
so it is unfortunate that i cannot use the vst rubber bands from nuendo and have all that range to play with. i am stuck with midi again..!! :/
I may try to simulate a Mac on my PC?? I’ve heard that done before. unless anyone else here uses pluggo and maybe logic to run a test?? woooo yeah that would be cool to see. : P
teqy : )
You must be logged in to reply to this topic.