halo list.
i noticed that when a [netsend] tries to connect to another port the audio-output gets interrupted. in fact it's not only audio but the whole gui is blocked. especially when the destination port is not found immediately (which often is the case in my setup) that detail is very annoying.
in x_net.c at line 77ff i probably found the reason for this behavior:
////////// post("connecting to port %d", portno); /* try to connect. LATER make a separate thread to do this because it might block */ if (connect(sockfd, (struct sockaddr *) &server, sizeof (server)) < 0) { sys_sockerror("connecting stream socket"); sys_closesocket(sockfd); return; } /////////
does anybody already have a nonblocking version of [netsend] he would be willing to share? or any hints on how to insert such a thread? miller?
bang a lot. joreg.
Joreg Diessl schrieb:
i noticed that when a [netsend] tries to connect to another port the audio-output gets interrupted. in fact it's not only audio but the whole gui is blocked.
Hi Joreg,
I know this problem very well...
/* try to connect. LATER make a separate thread to do this because it might block */
well, it's not only netsend that can block Pd. I'm working on multithreaded versions of my oggcast~, oggamp~ and shoutamp~ externals since they behave the same. streamin~ and streamout~ have the same problem...
But the multithreading code is quite huge compared to the desired effect. I'm sorry but I don't have such a version of netsend but oggamp~ 0.2 (with multithreading) will be finished quite soon. Maybe it's possible to reuse the code.
In general, I think, it would be a good idea to have Pd running two different threads by default. I know it's a lot of work to do but that way we could seperate time critical calculations (like dsp) from all the other things. The GUI is sort of seperated because it's in fact a seperate process.
Olaf
-
Joreg Diessl -
Olaf Matthes