On Sun, 17 Dec 2006, Roman Haefeli wrote:
netpd's major problem is the occurence of many dropouts in certain situations. one reason is the way how all (at least all i know) network related objects in pd handle buffer overruns. when the buffer of a network object is full, the whole pd processing is stopped until the buffer gets emptied again.
Pd doesn't handle all of its sockets like that. There's one special socket that handles it differently, and it's the socket that talks to the GUI process. In Pd 0.38, Miller added a bunch of special code in s_inter.c that allows it to do nonblocking writes and causes it to replace the output buffer by a bigger one.
The problems that I see with that are:
- there's no way to limit the size of the output buffer. If the other
side of the connection doesn't respond, the sending buffer just inflates quickly. I've seen it happen that a bug in the sender causes it to try to send so fast that it ate memory like an infinite recursion or a forkbomb.
- That operation is not realtime-safe (but still it's much closer to
being so than just blocking...)
It's only usable by the GUI socket and never by [netsend].
While that buffer together with t_guiqueue allow GUI updates to be
delayed for as long as necessary, it doesn't solve the problem that it can send information that is already outdated and redundant. This can be important in preventing problem #1 for a very heavy GUI. DesireData has had this problem essentially dealt with since a long time, but it lacks some fine tuning to get more robust.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada