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