Hi Iain. To be honest, I didn't think about the problem that a message could need more than one packet. It's good to know that iemnet/tcpclient can handle that.
@IOhannes: thanks for the suggestion. And (binary) 0 is indeed the terminating character. On Mon, Jul 1, 2013 at 10:14 PM, Iain Mott <m...@reverberant.com> wrote: > Using iemnet/tcpclient and implementing IOhannes parsing suggestion, my > patch is now communicating with SSR without crashing. There is a > "bogging down" problem though and testing with just 3 sources, I need to > keep the limit at 10 messages/sec for each. It stops working at higher > rates but doesn't crash. SSR is running on this local machine and there > is no WiFi involved. Unfortunately I don't think UDP is an option with > SSR. No sorry, not for now. But feel free to hack into the SSR code! > SSR also sends XML "level" data to tcpclient constantly for each source > in the scene. Perhaps this extra traffic isn't helping. eg. > > <update><source id='1' level='-98.5405'/><source id='2' > level='-99.8139'/><source id='3' level='-99.6628'/><source id='4' > level='-101.127'/></update> > > I'll wait to hear back from SSR to see if they have any suggestions. I guess you are talking to me ... There is one quick and hackish way to avoid the level messages: Go to src/boostnetwork/connection.cpp (around line 102) and remove the line _subscriber.send_levels(); ... and recompile. This should get rid of the annoying "level" messages. The SSR still sends all other messages, but if desired you can disable them in a similar manner. I'm aware that this isn't a satisfactory long-term solution, but for now it may help. We have big plans to modularize the network interface of the SSR in a way that different network protocols can be used interchangeably, e.g. WebSockets, FUDI, OSC, ... MIDI could probably also be included there. In addition, we want to implement a publish-subscribe mechanism (for all protocols which have a back-channel) which allows clients to select the exact amount (and probably rate) of information to receive from the SSR. However, currently we just don't have the resources to make these changes. @list: if anyone wants to help feel free to contact us: s...@spatialaudio.net! BTW, some advertisement: Did everyone check out the brand new "preview" version of the SSR: http://spatialaudio.net/ssr/download/? It also features multi-threading and the brand new (and still quite experimental) NFC-HOA renderer! cheers, Matthias > Cheers and thanks for your help everyone, > > Iain > > > > > > > > Em Mon, 2013-07-01 às 14:29 -0400, Martin Peach escreveu: >> Forty times a second is relatively slow. Must be something else. I would >> use wireshark to see what packets are actually going over the wire, >> especially to see what the last one is. >> These speeds are probably too fast for [print]ing to the console; that >> can cause problems. >> Are you sending to the same machine? If not is WiFi involved? >> Can you use UDP instead of TCP (for lower overhead and no out-of-order >> packets)? >> >> Martin >> >> On 2013-07-01 13:58, Iain Mott wrote: >> > Hi Martin, >> > >> > The actual patch I'm using is translating MIDI pitch bend data recorded >> > in Ardour3 (location data encoded as pitchbend for practical purposes), >> > translating it into XML and sending it through to the SSR. It's already >> > limiting the rate to 10 messages every second for each moving source and >> > so far I'm only using 4 sources. This rate, done for testing, is already >> > less than ideal. Each location message sent SSR for a given source looks >> > something like the following: >> > >> > <request><source id=1"><position x="1.234" >> > y="-0.234"/></source></request> >> > >> > Does this seem excessive? >> > >> > Cheers, >> > >> > Iain >> > >> > >> > >> > Em Mon, 2013-07-01 às 13:20 -0400, Martin Peach escreveu: >> >> It could be that you are overloading Pd with too many messages. If you >> >> are wildly moving the slider and [tcpclient] is sending one TCP packet >> >> per value you can add messages to the queue faster than they will be >> >> sent out and Pd will eventually run out of resources. >> >> >> >> Maybe put a [speedlim] after your slider, or pack several values into >> >> one message? >> >> >> >> Martin >> >> >> >> >> >> >> >> On 2013-07-01 11:53, Iain Mott wrote: >> >>> >> >>>>> I'll try the backtrace and other things you suggest and report back >> >>>>> on mrpeach/tcpclient in another email. >> >>>> >> >>>> it could well be, that it only does not crash with [iemnet/tcpclient] >> >>>> because you haven't parsed the output yet... >> >>>> >> >>> >> >>> Don't think so - to crash Pd, I wasn't doing any parsing of incoming >> >>> messages - just sending messages out. >> >>> >> >>> Did a backtrace using mrpeach/tcpclient - on a "freeze" as it didn't >> >>> actually crash. Got this response: >> >>> >> >>> #0 0x0000000000442623 in clock_unset (x=0x8c5c80) at m_sched.c:70 >> >>> #1 clock_unset (x=0x8c5c80) at m_sched.c:62 >> >>> #2 0x000000000044266e in clock_set (x=0x8c5c80, setticks=<optimised >> >>> out>) >> >>> at m_sched.c:81 >> >>> #3 0x00007fffd21cfec1 in tcpclient_child_send (w=0xdec548) >> >>> >> >>> at /home/kiilo/Documents/dev/pd-svn/externals/mrpeach/net/tcpclient.c:380 >> >>> #4 0x00007ffff7bc4e9a in start_thread () >> >>> from /lib/x86_64-linux-gnu/libpthread.so.0 >> >>> #5 0x00007ffff6ec0ccd in clone () from /lib/x86_64-linux-gnu/libc.so.6 >> >>> #6 0x0000000000000000 in ?? () >> >>> >> >>> >> >>> Will do some more tests later. >> >>> >> >>> Thanks, >> >>> >> >>> >> >>> _______________________________________________ >> >>> Pd-list@iem.at mailing list >> >>> UNSUBSCRIBE and account-management -> >> >>> http://lists.puredata.info/listinfo/pd-list >> >>> >> >>> >> >> >> > >> > >> > >> > >> > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list