Booting Server Error

Questions
1

Hey, Every time I try to boot local server I get…

Booting server ‘localhost’ on address 127.0.0.1:57110.
Server ‘localhost’ exited with exit code 0.

V new to SC so sorry if there is a simple reason for this that I’ve missed.

Any ideas?

2

you should add some info, e.g. which OS you are using

best

3

Apologies,

macOS Mojave

SuperCollider 3.11.2

Cheers

4

Same problem here.
macOS Mojave 10.14.6
SuperCollider 3.11.2

When starting SuperDirt, I get the following output in the console immediately:

Booting server 'localhost' on address 127.0.0.1:57110.
Server 'localhost' exited with exit code 0.

Tried changing the sample rate and device when booting in startup.scd, like that:

(
s.reboot { // server options are only updated on reboot
	Exception.debug = true;
    // configure the sound server: here you could add hardware specific options
    // see http://doc.sccode.org/Classes/ServerOptions.html
    s.options.numBuffers = 1024 * 256; // increase this if you need to load more samples
	s.options.sampleRate = nil; // also tried with 44000 value
    s.options.memSize = 8192 * 32; // increase this if you get "alloc failed" messages
    s.options.numWireBufs = 64; // increase this if you get "exceeded number of interconnect buffers" messages
    s.options.maxNodes = 1024 * 32; // increase this if you are getting drop outs and the message "too many nodes"
    s.options.numOutputBusChannels = 2; // set this to your hardware output channel size, if necessary
    s.options.numInputBusChannels = 2; // set this to your hardware output channel size, if necessary
	s.options.device = "Duet USB";

    // boot the server and start SuperDirt
    s.waitForBoot {
        ~dirt = SuperDirt(2, s); // two output channels, increase if you want to pan across more channels
        ~dirt.loadSoundFiles;   // load samples (path containing a wildcard can be passed in)
        // for example: ~dirt.loadSoundFiles("/Users/myUserName/Dirt/samples/*");
        // s.sync; // optionally: wait for samples to be read
        ~dirt.start(57120, 0 ! 12);   // start listening on port 57120, create two busses each sending audio to channel 0

        // optional, needed for convenient access from sclang:
        (
            ~d1 = ~dirt.orbits[0]; ~d2 = ~dirt.orbits[1]; ~d3 = ~dirt.orbits[2];
            ~d4 = ~dirt.orbits[3]; ~d5 = ~dirt.orbits[4]; ~d6 = ~dirt.orbits[5];
            ~d7 = ~dirt.orbits[6]; ~d8 = ~dirt.orbits[7]; ~d9 = ~dirt.orbits[8];
            ~d10 = ~dirt.orbits[9]; ~d11 = ~dirt.orbits[10]; ~d12 = ~dirt.orbits[11];
        );
    };

    s.latency = 0.3; // increase this if you get "late" messages
};
);

But no luck.

I am using Apogee Duet audio interface + running Sonarworks Reference (eq-ing studio monitors, it hijacks the output device), which might be messing with the devices routing, do you think this could be the issue?

Any tips on how to debug this issue would be very welcomed.

Thanks!

5

I’m not on Mac so I might be missing some details.

That’s possible, I suppose. One way to check that is through differential testing:

  • SC + Apogee + Reference = failed
  • SC + Apogee - Reference (i.e., disable Reference) = ??
  • SC + other audio device (even the built-in soundcard) = ??

Another differential tests to try: What if you only s.boot without any of the SuperDirt instructions? (I guess it won’t make a difference, but worth trying.)

If it’s crashing, running scsynth in the XCode debugger might show exactly where it’s crashing. Again, I’m not on Mac so I can’t give you detailed instructions on XCode, but the general process would be:

  1. In sclang, do s.options.asOptionsString and copy the string (without ->) from the post window.

  2. In the debugger, run scsynth and append the options string after that, e.g. scsynth -u 57110 -a 1024 -i 2 -o 2 -m 524288 -R 0 -C 1 -l 1.

Then, if the process crashed, you would see something to that effect on screen. In that case, look up online how to read stack traces in XCode.

Or maybe the process is just exiting… in which case, I’m not sure what you would see.

Or (and this would be strange) maybe it boots successfully in the debugger… then you could try Server.default = Server.remote(\debug, NetAddr("127.0.0.1", 57110), s.options) and continue with SuperDirt – this is in case it’s crashing after boot. I think this is extremely unlikely, but who knows?

@nosrepnu Is there anything special about the audio device you’re using?

Although… usually scsynth will print errors about connecting to the audio device.

It’s a strange problem.

hjh

7

Can you post the output of ServerOptions.devices with the Sonarworks thing running? I’m guessing that you should use that device (or system default device) instead of s.options.device = "Duet USB".

8

Thank you @MarcinP @jamshark70 for your fast reply!

The output of ServerOptions.devices is [ Built-in Microph, Built-in Output, HDMI, Duet USB, Sonarworks Systemwide, ZoomAudioD ].

I tried different variations: shutting down the Sonarworks, unplugging the audio interface, setting the device to Sonarworks Systemwide, starting with just s.boot - didn’t get any difference.

While browsing through the different similar threads, I noticed that people do not often get the message Server 'localhost' exited with exit code 0. immediately after Booting server 'localhost' on address 127.0.0.1:57110.. For example, it usually also gets printed out the device options, what it boots with, etc.

Do you have any idea why it might be immediately exiting with code 0?

Also, I see in related threads people having issues because of Jack. I tried installing it yesterday (QJackCtl) but didn’t figure out what exactly to do with that. If anyone is on OS X, did you guys do any setup with the Jack?

Thanks for help <3

9

Looking at the source – this is an absolutely bizarre conjecture – but one way it could be exiting immediately with 0 is if EventLoop::run([world]() { World_WaitForQuit(world, true); }); is not in fact waiting for quit.

I can’t imagine why that would fail, but… @MarcinP, am I totally barking up the wrong tree or is there something to that?

hjh

10

@crdhd

I tried different variations: shutting down the Sonarworks, unplugging the audio interface, setting the device to Sonarworks Systemwide , starting with just s.boot - didn’t get any difference.

That’s unfortunate…
Not sure if we’re chasing the correct issue here but to be sure I would try:

  • removing (e.g. commenting out) everything in the startup file
  • removing all the quarks (e.g. by switching to the new language config file in the IDE interpreter preferences)

After each step and restarting SC (or the interpreter) just run s.boot.

Also, I see in related threads people having issues because of Jack.

Forget Jack (for the purpose of your issue) - these must be largely obsolete threads, as the only Jack that SC could work with (*) is JackOSX, which provided JackRouter, and only works up to macOS Mojave (10.14). The “current” Jack2 does not provide JackRouter and thus SC can’t use it.

@jamshark70

I can’t imagine why that would fail, but… @MarcinP, am I totally barking up the wrong tree or is there something to that?

I’m really not sure.

But I agree, that if the server exits right away, the issue is likely before the audio driver gets initialized.
If the server is not able to open the udp port, then at least an appropriate message is posted…

Another thing to test: are you able to run scsynth from the terminal?

/Applications/SuperCollider.app/Contents/Resources/scsynth -u 57110

(Adjust the path if you have SuperCollider in a subfolder etc)

(*) Just for completenss sake - one can compile SC with Jack support on macOS, but we don’t provide a download like that.

11

I decided to go through the installation process from scratch, so I wiped off all the libs and reinstalled them, and it seems to be working now. Yesterday remember having some issues while installing, so maybe that was the problem.

Can confirm that I am currently able to produce sounds via tidal.

Thanks for your fast support, guys! :innocent: