On Mon, 3 Jul 2006, Martin Peach wrote:
but we all know single-threaded design is bad, and its not like i can code C without turning an uninhabited island to Segfault City, so i'll be quiet. :)
[netclient] uses a new thread for each connection. Maybe it would work better...
Right, that may be the difference. netreceive receives will execute all the commands it receives immediately and before doing any audio calculation. Depending on what is going on this might be too much. A threaded implementation will distribute the messages over several dsp cycles, making it smoother.
If this is true, then putting a netreceive in the audio patch and not connecting should not show the bad behaviour.
Also, it would be interesting to know how the patch behaves if the same amount of messages get triggered without a network connection.
Anyhow, netsend/netreceive on their own should not be different in their performance than OSC or any other implementation, it might be due to the way the object schedules incoming messages.
It might be that the threaded implementation just drop some of the messages if they are not able to keep up with the traffic.
Guenter
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list