/quit occationally only stops audio thread but not the scsynth process

[LFSaw]

recreate this by running (probably repeatitively):

on BBB

scsynth -u 57110 -z 16 -J 8 -K 8 -G 16 -i 2 -o 2

watch on BBB for what is there by running (in a separate terminal)

watch -n 0.5 cat /proc/xenomai/stat

quit server from SC:

NetAddr("192.168.7.2", 57110).sendMsg(\quit)

[sensestage]

I cannot reproduce.

just calling s.quit works fine...

[sensestage]

The message should be "/quit" - so forward slash

[sensestage]

The bug happens sometimes - not at all times.

[sensestage]

This really seems to be an issue with the semaphore lock...

[sensestage]

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.

[giuliomoro]

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)?

[sensestage]

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.

[sensestage]

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.

[giuliomoro]

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 ?))

[sensestage]

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...

[sensestage]

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.

[giuliomoro]

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?

[giuliomoro]

@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?

[giuliomoro]

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)

[giuliomoro]

Have you had a chance to test this with the latest Bela code?

[sensestage]

Seems fine now.