Here's a guess... if incoming (vanilla) netreceive traffic is swamping Pd, then since Pd prioritizes input from GUI above output back to GUI, the output never gets scheduled. If that were happening, you'd see the windows freeze but still be able to send Pd events from the GUI (hitting buttons in the patch, for instance.)
I haven't recreated the situation myself yet, but will do that at some point to try to get a better idea.
At any rate, it's likely that incoming net traffic is also getting dropped - not a good scenario. Ideally there should be a some way for Pd to sense that so that the patch could send out requests to slow the flow down before it starts dropping packets.
In the meantime, a possible workaround: send occasional pings to the receiving Pd, hav ethe Pd patch echo the pings back to tne sending patch, and have the sending patch not allow more than a certain number of other messages go out between pings.
cheers Miller
On Sun, Aug 07, 2011 at 11:56:45AM -0400, Ivica Ico Bukvic wrote:
If you are indeed talking about vanilla netsend and netreceive, the poll function is called during pd's main loop, not when something arrives at the socket. In x_net.c : sys_addpollfn(sockfd, (t_fdpollfn)socketreceiver_read, y); socketreceiver_read is in s_inter.c: void socketreceiver_read(t_socketreceiver *x, int fd) sys_addpollfunction schedules the function to be called each pass through Pd's main loop.
Martin
If that is the case, then it seems the bug lies elsewhere but is there nonetheless. The clock_delay workaround has fixed this in pd-l2ork permanently and I am yet to experience gui freeze that has been plaguing our setup way too often before the said workaround.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list