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.
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. 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