Closed giuliomoro closed 6 years ago
This affects the .poll method
Funny fact:
running scsynth
, scprintf()
will work fine.
Running sclang
, the scprintf()
of the spawned process will not work fine.
Even more: if you start sclang
and then kill -2 \
pgrep scsynth`(or
kill -2the pid of the audio thread), it will dump all the
scprintfmessages you printed earlier and were not actually printed . However, if you ctrl-c
sclang` it will die immediately without dumping those messages. Still, the PRU will stop correctly (which somehow means that the signal handler (see #11) is getting called, but the messages are not dumped.).
As suggested by @apmcpherson, this can totally be an issue of buffering of the stdout
of scsynth
when started by sclang
. However, I tried to make sclang
start scsynth
with stdbuf -i 0 -o 0 -e 0 scsynth
(which should prevent buffering of stdout/in/err
) instead of exec scsynth
and this does not yield any improvement. example patch:
diff --git a/SCClassLibrary/Platform/linux/LinuxPlatform.sc b/SCClassLibrary/Platform/linux/LinuxPlatform.sc
index 19566f1..c2724ad 100644
--- a/SCClassLibrary/Platform/linux/LinuxPlatform.sc
+++ b/SCClassLibrary/Platform/linux/LinuxPlatform.sc
@@ -10,7 +10,7 @@ LinuxPlatform : UnixPlatform {
helpDir = this.systemAppSupportDir++"/Help";
// Server setup
- Server.program = "exec scsynth";
+ Server.program = "stdbuf -o0 -i0 -e0 scsynth";
// Score setup
Score.program = Server.program;
note that if I run exec stdbuf -o0 -i0 -e0 scsynth
it just fails (scsynth
process becomes defunct).
so I have a fix for this, but then if I use poll()
in SC, the console gets flooded with messages. @sensestage do you know how poll() is implemented (e.g.: in something like:
var rate = AnalogIn.ar(0).exprange(0.3, 20);
rate.poll(100);
) ? Where is this poll()
implemented?
This is the patch which flushes the rt_printf
buffers from a separate thread and outlines the issue above:
diff --git a/server/scsynth/SC_Bela.cpp b/server/scsynth/SC_Bela.cpp
index 8e34305..ee91360 100644
--- a/server/scsynth/SC_Bela.cpp
+++ b/server/scsynth/SC_Bela.cpp
@@ -327,6 +327,7 @@ void SC_BelaDriver::staticMAudioSyncSignal(void*){
// ... but mode switches are still happening here, in a lower priority thread.
// FIXME: this triggers a mode switch in Xenomai.
staticMAudioSync->Signal();
+ rt_print_flush_buffers();
rt_task_suspend(rt_task_self());
}
Right, my fix is fine. The "flooding" I experienced above is related to another issue.
Merge PR #60 to fix this.
That's funny. I believe it is a xenomai issue:
scprintf
is set to callrt_vprintf
, which in turn requires a call tort_print_auto_init(1)
to properly work (though this does not seem to be always the case). Anyhow, it boils down to: "rt_vprintf
does not work whenscsynth
is started bysclang
".So for now, do not rely on the output from
scprintf
when runningsclang
.