[PD] netsend/netreceive + GUI bug

Miller Puckette msp at ucsd.edu
Sun Aug 7 21:43:53 CEST 2011


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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



More information about the Pd-list mailing list