Re: UDP address in use but no scsynth running..

yes, that sounds very likely to be the issue. Well, maybe I will put a support ticket up at Waves. Would be very cool indeed if they fix something to make their plugin work in SuperCollider. I can check if it happens with Max too, to make my case stronger ;-).

Thanks for the quick analysis,
cheers, Wouter

> Op 4 mrt. 2021, om 12:26 heeft [email protected] het volgende geschreven:
> 
> Glad you found the issue!
> 
> 
>> Or could it be something in VSTPlugin causing this?
> I don't think so. VSTPlugin doesn't do anything related to sockets.
> 
> 
>> I guess this problem is too specific for a generic fix
> I think there is no way to fix this in VSTPlugin. Write a support e-mail to Waves :-)
> 
> 
>> although I would be interested to know why this happens
> If you're on Windows, I have no idea.
> 
> ---
> 
> If you're on macOS, then it might be related to the behavior of fork(), which duplicates all open file descriptors of the parent process. So what I think happens is this:
> 
> The Waves Nx plugin calls fork() + exec() to start a subprocess. That subprocess inherits the scsynth UDP socket. When scsynth shuts down, it closes the socket, but the same socket is still open in the subprocess, so the listening port is not available until the subprocess closes.
> 
> There are ways to work around this in scsynth, e.g. calling fcntl(socket, F_SETFD, FD_CLOEXEC) on the UDP socket, but I think, it needs rather be fixed in the WavesLocalServer app.
> 
> Generally, you should close all existing file descriptors (that you don't need) at the beginning of the child process. Often you can ignore this and be fine if the process is shortlived and/or doesn't outlive the parent process, otherwise you can run into troubles like this.
> 
> Christof
> 
> On 04.03.2021 10:05, [email protected] <mailto:[email protected]> wrote:
>> Ok, I got a bit further on this. The problem is actually limited to the Waves Nx plugin (which I use for binaural headtracked preview). It opens a process named WavesLocalServer, which in turn opens the same udp port as the server (not using it for anything as far as I can tell). This process keeps existing after the plugin is closed, blocking any future starting up of the server at that address. Doing a simple 
>> 
>> $ killall WavesLocalServer 
>> 
>> in terminal fixes the issue. I guess this problem is too specific for a generic fix, although I would be interested to know why this happens. Could it be that any child process opened by the server is automatically granted the same ports as the server itself, perhaps by the os? Or could it be something in VSTPlugin causing this? The WavesLocalServer process is also opened when using the plugin for example in Live, but then it doesn't open any UDP ports. It does always open a TCP port which I presume is used for communication with the headtracker application.
>> 
>> Anyway, puzzling but at least I know a bit of what's going on now and how to fix without rebooting. Perhaps this could be a heads-up thread for anyone else using Waves Nx in SuperCollider ;-).
>> 
>> cheers,
>> Wouter
>> 
>>> Op 2 mrt. 2021, om 22:39 heeft [email protected] <mailto:[email protected]> het volgende geschreven:
>>> 
>>> I don't see how this could be caused by the VSTPlugin extension... But if you are really sure that the issue is caused by VSTPlugin, please open a bug report: https://git.iem.at/pd/vstplugin/-/issues <https://git.iem.at/pd/vstplugin/-/issues>. Provide a minimal code example which triggers the issue and list all relevant system information (VSTPlugin version, SC version, OS version).
>>> 
>>> Christof
>>> 
>>> On 02.03.2021 15:37, [email protected] <mailto:[email protected]> wrote:
>>>> Yes, it seems to cause the issue. Whenever I open a VST plugin, then quit the server and try to start it again it fails. But, when changing the servers NetAddr port to 57111 (just to try a different one) the issue doesn't occur anymore, even when opening and closing VST's. Weird..
>>>> 
>>>> I also tried the other way around; after a fresh restart, start server on port 57111, open a VST on it, free it and quit server. Now port 57111 stays open and port 57110 can be used normally (even with VST's). With nmap I can also see it (after quitting the 57111 server):
>>>> 
>>>> $ sudo nmap -sU -p57110-57111 127.0.0.1
>>>> ...
>>>> 57110/udp closed        unknown
>>>> 57111/udp open|filtered unknown
>>>> ...
>>>> 
>>>> This could provide a workaround to at least be able to work, but something pretty fishy seems to be going on here..
>>>> 
>>>> cheers,
>>>> Wouter
>>>> 
>>>>> Op 2 mrt. 2021, om 14:26 heeft [email protected] <mailto:[email protected]> het volgende geschreven:
>>>>> 
>>>>>> I do have the VSTPlugin extension installed btw, maybe that is related?
>>>>> I don't think so, but that's easy to test: temporarily uninstall
>>>>> "VSTPlugin" and see if it resolves the problem.
>>>>> 
>>>>> Christof
>>>>> 
>>>>> On 02.03.2021 14:23, [email protected] <mailto:[email protected]> wrote:
>>>>>> Hi list,
>>>>>> 
>>>>>> I'm running SC3.11.2 and I'm getting the old:
>>>>>> 
>>>>>> *** ERROR: failed to open UDP socket: address in use.
>>>>>> 
>>>>>> a lot. It usually happens after quitting and (re-)starting SC. Of course I know that this usually means a stray server is around, but Server.killAll doesn't do the trick and there are no scsynth processes around in the activity monitor. The message goes away only after a reboot of the machine. Any ideas what could be going on here? Running macOS 10.14.6 Mojave, tried signed, unsigned and the new big sur build (the latter doesn't give the message, but still says "Server 'localhost' exited with exit code 1."). I do have the VSTPlugin extension installed btw, maybe that is related?
>>>>>> 
>>>>>> 
>>>>>> cheers & thanks,
>>>>>> Wouter
>>>>>> _______________________________________________
>>>>>> sc-users mailing list
>>>>>> 
>>>>>> info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx <http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx>
>>>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ <http://www.listarc.bham.ac.uk/marchives/sc-users/>
>>>>>> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ <http://www.listarc.bham.ac.uk/lists/sc-users/search/>
>>>>> 
>>>>> _______________________________________________
>>>>> sc-users mailing list
>>>>> 
>>>>> info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx <http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx>
>>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/ <http://www.listarc.bham.ac.uk/marchives/sc-users/>
>>>>> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/ <http://www.listarc.bham.ac.uk/lists/sc-users/search/>
>>>> 
>>