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:
1. 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.
2. That operation is not realtime-safe (but still it's much closer to
being so than just blocking...)
3. It's only usable by the GUI socket and never by [netsend].
4. 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
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
