<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1487758192451_194158"><span id="yui_3_16_0_ym19_1_1487758192451_159788" style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;">> (so the order of data arrival is </span><span id="yui_3_16_0_ym19_1_1487758192451_159792" style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;">guaranteed). </span><br></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><span style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;"><br></span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><span style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1487758192451_160026">Well this is a design feature of UDP: there is no guarantee of whether packets are going to be received or in what order. If you use UDP, you MUST write your program in such a way that it is resilient to data loss and data order. If you don't, then you may encounter problems later down the line, when you are in less than ideal conditions.</span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><span style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;"><br></span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><span style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1487758192451_160032">This said, it seems that [mrpeach/net] is designed in such a way that out-of-order delivery occurs more often than with other systems. Good to test the resiliency of your system.</span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><span style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;"><br></span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif" id="yui_3_16_0_ym19_1_1487758192451_186666">My brief experience with net objects (I could be wrong, but this is what I remember):</font></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif"><br></font></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif" id="yui_3_16_0_ym19_1_1487758192451_186667">[netreceive] / [netsend]: they do the socket job in the audio thread. This gives the following deterministic behaviour: the message is written to the socket before the audio callback is performed. What it does not give is any deterministic guarantee about when the packet is going to go out of your interface or be delivered. So given the latter, I am not sure why the former matters.</font></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif"><br></font></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif" id="yui_3_16_0_ym19_1_1487758192451_193894">[iemnet/udpsend] / </font><span style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1487758192451_186843">[iemnet/updreceive]: threaded, for [udpsend] the packets are stored in memory from the audio thread. A worker thread reads them and writes them to the socket. Issue is the audio thread uses malloc() to store the stash the values in memory, so it may occasionally hang while waiting for the kernel to provide more memory.</span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><span style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;"><br></span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><span style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1487758192451_187033">[mrpeach/net] have not looked at the code in person, but it has been mentioned here that it uses multiple working threads. </span><span style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1487758192451_193825">If threads are created within the audio thread (as opposed to using a fixed pool of workers that get "activated" from the audio thread), then this also will occasionally hang while waiting for the kernel.</span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><span style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;"><br></span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><span style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1487758192451_193826">None of the approaches above is workable on the platform I am working on (Bela), as - running under Xenomai - the usual constraints that apply to audio programming (no I/O, no allocation, no creating threads in the audio thread) are even more strict (i.e.: you REALLY need to follow these principles).</span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><span style="font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif;" id="yui_3_16_0_ym19_1_1487758192451_192727">My tentative approach was to turn [netreceive] into a threaded object, using a lock-free queue beween the threads (the one provided by libpd), using ifdefs to reuse most of the existing vanilla code. </span></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><font face="HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif" id="yui_3_16_0_ym19_1_1487758192451_193067"><a href="https://github.com/giuliomoro/pure-data/commits/Bela-net" id="yui_3_16_0_ym19_1_1487758192451_193827">https://github.com/giuliomoro/pure-data/commits/Bela-net</a></font><br></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr">I am not quite happy with it yet: the code looks like a mess with all the ifdefs, and [netsend] is not working atm, but [netreceive] now can be safely used. I guess it would be better if I were to package it as an external, removing the ifdefs.</div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><br></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr">Giulio</div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><br></div><div class="qtdSeparateBR" id="yui_3_16_0_ym19_1_1487758192451_159773" dir="ltr"><br></div><div class="yahoo_quoted" id="yui_3_16_0_ym19_1_1487758192451_159744" style="display: block;"> <div style="font-family: Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1487758192451_159743"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;" id="yui_3_16_0_ym19_1_1487758192451_159742"> <div dir="ltr" id="yui_3_16_0_ym19_1_1487758192451_159772"> <font size="2" face="Arial" id="yui_3_16_0_ym19_1_1487758192451_159771"> <hr size="1" id="yui_3_16_0_ym19_1_1487758192451_187026"> <b><span style="font-weight:bold;">From:</span></b> Roman Haefeli <reduzent@gmail.com><br> <b><span style="font-weight: bold;">To:</span></b> pd-list@lists.iem.at <br> <b><span style="font-weight: bold;">Sent:</span></b> Wednesday, 22 February 2017, 15:19<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [PD] netsend/netreceive questions ...<br> </font> </div> <div class="y_msg_container" id="yui_3_16_0_ym19_1_1487758192451_159741"><br>On Mit, 2017-02-22 at 15:41 +0100, IOhannes m zmoelnig wrote:<div class="yqt9051497495" id="yqtfd98222"><br clear="none"><br clear="none">> mrpeach/net should block less than the built-in object, but in theory<br clear="none">> it<br clear="none">> might still block when spinning up to many threads.<br clear="none">> also mrpeach/net is prone to race-conditions, where one sending<br clear="none">> thread<br clear="none">> can overtake another sending thread (so the order of data arrival is<br clear="none">> not<br clear="none">> guaranteed). obviously mrpeach/net doesn't always exihibit that<br clear="none">> problem<br clear="none">> (else nobody would use it), but iirc i was able to trigger that<br clear="none">> behaviour in a lab situtation.</div><br clear="none"><br clear="none">netpd - as an example of a non-lab situation - does trigger such<br clear="none">problems with mpreach/net. Last time I checked, it presented incoming<br clear="none">data as lists which suggests that it uses some auto-magic internal<br clear="none">delimiting function, but it does not, it relies on pure chance. It's a<br clear="none">misconception that the author refuses to address. <br clear="none"><br clear="none">As far as I can tell, mrpeach/net suffers issues that iemnet does not.<br clear="none">I don't see any advantage in using mrpeach/net besides the fact that<br clear="none">Pd-l2ork / Purr Data - due to their Pd-extended heritage - come with<br clear="none">mrpeach and not with iemnet. <br clear="none"><br clear="none">Roman<br><div class="yqt9051497495" id="yqtfd64211">_______________________________________________<br clear="none"><a shape="rect" ymailto="mailto:Pd-list@lists.iem.at" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br clear="none">UNSUBSCRIBE and account-management -> <a shape="rect" href="https://lists.puredata.info/listinfo/pd-list" target="_blank">https://lists.puredata.info/listinfo/pd-list</a><br clear="none"></div><br><br></div> </div> </div> </div></div></body></html>