Server ready but not running

Questions
1

Hi,

I’m having some issues with the server. I’m not sure if it’s been happening since the last upgrade a couple days ago [2022-09-19T10:09:26+0200] [ALPM] upgraded supercollider (3.12.2-2 -> 3.12.2-3).

When I run s.boot no errors are posted but the server does not boot (although it says it’s ready there’s no info coming from the server either – I get no Ugen or CPU usage feedback, yellow color and all zeroes in ScIDE’s server window, and all dashes in powerline in emacs):

-> localhost
Booting server 'localhost' on address 127.0.0.1:57110.
Found 115 LADSPA plugins
Faust: supercollider.cpp: sc_api_version = 3
Faust: FaustJPverbRaw numControls=11
Faust: supercollider.cpp: sc_api_version = 3
Faust: FaustGreyholeRaw numControls=7
JackDriver: client name is 'SuperCollider'
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 1024
JackDriver: connected  UMC404HD 192k Analog Surround 4.0:capture_FL to SuperCollider:in_1
JackDriver: connected  UMC404HD 192k Analog Surround 4.0:capture_FR to SuperCollider:in_2
JackDriver: connected  SuperCollider:out_1 to UMC404HD 192k Analog Surround 4.0:playback_FL
JackDriver: connected  SuperCollider:out_2 to UMC404HD 192k Analog Surround 4.0:playback_FR
SuperCollider 3 server ready.
JackDriver: max output latency 32.0 ms

but then, when I try to do something like {SinOsc.ar * 0.1}.play I get this warning:

WARNING: server 'localhost' not running.
-> nil

MIDI does work, though. I guess it does because it doesn’t need the server.
I’m running SC on Linux localhost 5.19.9-arch1-1 x86_64 GNU/Linux using Pipewire.

Any hints on what may be going on?

2

Could you make sure that scsynth isn’t running already, sometimes it gets stuck if there’s another instance?
killall scsynth

3

That’s the first thing I checked. It happens even on a fresh system start

4

Okay, are you compiling from source? If so it might be that the plugins need recompiling too. If not, you could try removing all of them (temporarily) and see what happens.

5

I’m installing it using pacman from the official repo. My guess is that it downloads the binary, I don’t see any compiling taking place. I tried reinstalling both supercolliderand sc3-plugins. It didn’t work.

By “removing the plugins” do you mean sc3-plugins or the quarks?

6

scsynth shows up in the task manager, but it doesn’t work (?)

7

try temporarily moving everything out of /usr/local/share/SuperCollider/Extensions and ./local/share/SuperCollider/Extensions. I think whats happening is its stuck loading a library that is incompatible.

8

I’ve tried removing all of these, and the downloaded-quarks. The problem persists…

9

Perhaps scsynth isn’t reachable through the network protocol (for some reason).

You’ve got the entire boot process up to the point where the language has to login/handshake. So I’d guess this communication may be the problem.

hjh

10

Is there a way to check/fix this?

11

Sometimes Server.killAll will fix this. The problem here might be lying with sclang.

wait … are you actually using Pipewire? I’ve never been able to get it to work - jack runs fine though. Have you checked without?

It is worth mentioning 3.12.2-3 came out 3 days ago. Perhaps you’d be better off asking on the aur… but since your running arch already, why not just build from source yourself? If it turns out to be a package issue, that is.

12

I’ve been using it for a while now, without any problems. To check without Pipewire I need to remove it completely because it’s incompatible with jack. scsynth seems to boot normally, it would complain if it was a pipewire/jack issue, wouldn’t it?

It looks like so, doesn’t it?

I’ll do that. Thanks.

13

I’ll assume that “this” is referring to my comment that “scsynth isn’t reachable through the network protocol.”

To check it, I would suggest:

  1. Get the server’s commandline options string: s.options.asOptionsString.
  2. Copy it to the clipboard, from the post window.
  3. In a terminal window, type scsynth and then paste the options after it. Run that. You should get messages up to “SuperCollider 3 server ready.”
  4. Back in SC:
OSCFunc.trace(true, false);

NetAddr("127.0.0.1", 57110).sendMsg('/status');

If network communication is working, then the OSCFunc trace should print something like the following.

OSC Message Received:
	time: 190.950404379
	address: a NetAddr(127.0.0.1, 57110)
	recvPort: 57120
	msg: [ /status.reply, 1, 0, 0, 1, 10, 1.2693686485291, 1.2866289615631, 44100.0, 44098.776837442 ]

If you get nothing, then there are two possible explanations:

  1. Maybe network communication is broken in one direction or the other or both. (I can’t think of a test to tell the difference between these.) And, how to fix it, if it’s a network problem? I have no idea. I suspect that would be a system issue. There’s no good reason for UDP messages to be blocked within localhost.
  2. Or maybe scsynth is hanging (which could be Pipewire related). In that case, it might be helpful to run scsynth within gdb and dump a trace of all the threads.

BTW what exactly is your Pipewire vs JACK configuration? Your server startup log shows JACK messages, so, certainly scsynth thinks it’s hooking up to a JACK server.

hjh

14

I don’t get anything. How can I run scsynth with gdb and dump the trace?
I ran scsynth -u 57110 and got this output

Found 115 LADSPA plugins
Faust: supercollider.cpp: sc_api_version = 3
Faust: FaustJPverbRaw numControls=11
Faust: supercollider.cpp: sc_api_version = 3
Faust: FaustGreyholeRaw numControls=7
JackDriver: client name is 'SuperCollider'
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 1024
SuperCollider 3 server ready.
Zeroconf: failed to create client: Daemon not running

I don’t know why zeroconf is not enabled. I didn’t disable it.
I started the service manually with systemctl start avahi-daemon.service.
Now I get the OSC messages from the server, but only if I boot the server from a console with scsynth -u 57110, otherwise s.boot launches scynth but I get no messages from it.

I don’t have JACK installed, just Pipewire with all the drop-in replacements for jack, alsa, pulseaudio, …

15

The problem seems to be solved. I ran pacman -S pipewire to reinstall it – without having to remove it first because it has a lot of dependencies – and now it works. I have to patch the output of SC to the soundcard input manually (which used to be done autmatically), but at least it works.

Thanks for your help

16

Does this…

"SC_JACK_DEFAULT_OUTPUTS".setenv("system");

… not fix the routing?

1 Like
17

It seems to be working normally now. Thanks!