Hallo, geiger hat gesagt: // geiger wrote:
On Sat, 1 Jul 2006, IOhannes m zmoelnig wrote:
Acutally I did this the other way around: I was forced to use OSC instead of netsend because netsend stalled one of the two Pds running, threw it off the jack graph and did other nasty things. So I just
interesting and good to know. thanks
however, there was one reason a forgot why we used netsend instead of OSC: it is built-in...
OSC and netsend 1 should not behave differently. If this is so, then there is something wrong in netsend. Did you use netsend with UDP ?
Yes, I tested both UDP and TCP, but mostly was using UDP. There was a longer thread regarding my problem a while ago - I guess it was here, may also have been on pd-dev. I'm conviced that there is something wrong with netsend, as Roman Haefli and also Georg Holzmann reported similar problems with netsend in that thread. IIRC Roman is using netserver instead, Georg fixed it by not running two instances of Pd.
It may only happen if you have to send much data. I also only run one Pd, the receiving one, in -rt mode. So the setup was this:
- GUI-Pd with Gem, noaudio, non-rt
- Audio-Pd without Gem, with audio, -rt, with or without GUI (didn't
matter)
After a short while I got terrible timing problems with the Audio-Pd, including stuttering etc. If running with Jackd there also were Jack underruns, and often jackd killed itself or dropped the connection to Pd.
Similar things happened with -oss or -alsa. As I said, using OSC instead of netsend fixed that issue (I still have this little abstraction which acts as the network bridge and which can be switched between sending over netsend/UDP or OSC.
Note that the symptoms happened on both my laptop and on my home machine.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__