Closed LFSaw closed 7 years ago
I cannot reproduce.
just calling s.quit works fine...
The message should be "/quit" - so forward slash
The bug happens sometimes - not at all times.
This really seems to be an issue with the semaphore lock...
The quit message is received and goes through all the stages (see supercollider/server/scsynth/SC_SequencedCommand.cpp
This mWorld->hw->mQuitProgram->post();
should cause
World_WaitForQuit
(line 447, supercollider/server/scsynth/scsynth_main.cpp
)
to stop from blocking, and then clean up in (line 780, supercollider/server/scsynth/SC_World.cpp
).
But that is not happening for some reason.
so how do you think this could be related with #16?
Do you think that is World_WaitForQuit()
is waiting for something like
staticMAudioSync->Signal();
but this does not come in (e.g.: because the AuxiliaryTask in which it runs has been killed)?
World_WaitForQuit()
waits for the semaphore to be unlocked: inWorld->hw->mQuitProgram->wait();
This is happening in Stage4 with mWorld->hw->mQuitProgram->post();
This is happening in different threads (as far as I understand what is going on), so I am wondering if there is something going wrong between the threads.
I guess the relationship that I am seeing is that there are issues with OSC communication not working well (especially when communicating from sclang running on another machine), the quit-message not being received well, and I have a feeling it is all boiling down to the problems in interprocess communication, or communication between threads. I am still wrapping my head around how everything works exactly within scsynth, as I haven't delved into this much detail into the architecture and code before.
Alright, can you explain to me how I can reproduce the issue exactly (please a step-by-step from starting the server/synth up to the point where the issue happens (how often does it happen ?))
start scsynth on bela in a terminal there:
scsynth -u 57110 -z 16 -J 8 -K 8 -G 16 -i 2 -o 2
from laptop in SC IDE execute this code, block by block:
// set up connection to scsynth on bela
Server.default = s = Server("belaServer", NetAddr("192.168.7.2", 57110));
s.initTree;
s.startAliveThread;
s.dumpOSC( 1 ); // check what osc the server receives (this is printed in the bela terminal
// just a synthdef to have something playing
(
SynthDef("AnalogIn",{ arg out=0;
Out.ar(out,
SinOsc.ar( AnalogIn.ar( 0 ).exprange( 200, 5000 ), 0, 0.1 )
)
}).send(s);
);
// instantiate it
a = Synth.new("AnalogIn", target: s).postln;
// check what osc is received back (goes into post window of SC)
OSCFunc.trace;
// send the quit message to the server
s.quit;
The problem happens about one in three times - haven't really found a pattern for it yet...
scsynth sends an osc message /done, /quit just before releasing the semaphore with mWorld->hw->mQuitProgram->post();
Running the synth is not actually necessary, even when nothing is running the error happens sometimes.
I failed to reproduce this with the method above (over 50 trials). I also tried to instantiate the synth multiple times so to increase the CPU load, but no luck: it always quits properly.
I moved s.dumpOSC(1)
above s.startAliveThread
. When sending s.startAliveThread
, there occasionally is a considerable lag before the long OSC message is displayed on the Bela terminal, is this expected?
@LFSaw you mentioned you do watch -n 0.5 cat /proc/xenomai/stat
. What are the processes that keep running when the scsynth process hangs?
Also, @LFSaw @sensestage : have you updated your Bela code recently?
It may well be that what you are seeing is the result of a bug that was fixed here on the dev branch.
I'd encourage you to upgrade to Bela's dev branch (as this has not been merged into master yet)
Have you had a chance to test this with the latest Bela code?
Seems fine now.
recreate this by running (probably repeatitively):
on BBB
watch on BBB for what is there by running (in a separate terminal)
quit server from SC: