Another important point is that if our servers are proper PipeWire clients they can enjoy PW benefits like running servers at different sampling rates. I think it is the case now that the whole JACK environment is treated the same and whatever process first starts it sets the samplerate for all that follow.
Another big long-term improvement for both JACK and PW would be to have sclang interface directly with the respective systems as a client so that you can query the graph, subscribe to and be notified of changes etc. This would be a big improvement to the current option which is running command line programs and interpreting the stdout output.
I wanted to give your experiment a try. Following your instructions I built scsynth and I could boot a server from commandline, even changing hardware buffer size to 64.
But I failed playing any sound. As following your instructions only builds scsynth I thought I could maybe run the code example from my SC 3.14 which I had already installed. However, sclang doesn’t recognize the server that I had already booted from commandline, only telling me that no server is running.
You have to use Server.remote to connect to a server that was booted outside of sclang.
o = ServerOptions.new;
/* set options in o, here */
Server.default = s = Server.remote(\remote, NetAddr("127.0.0.1", 57120), o);
Sclang doesn’t auto scan every port looking for active scsynth instances – that would be slow, and intrusive to other processes with open UDP ports. Hence, you have to tell sclang where to look.
Server.default = s = Server.remote(\remote, NetAddr("127.0.0.1", 57110), o);
… was what I was missing. I only had to change port 57120 to 57110 but sclang is now recognizing the server started from commandline (I don’t really understand what you meant by “Sclang doesn’t auto scan every port looking for active scsynth instances” - shouldn’t sclang automatically connect to port 57110 as given in Server.default.addr = NetAddr("127.0.0.1", 57110)?). Anyway, I’ll keep that in mind.
@Luc_Doebereiner : Yes! I have been able to produce sound running your example code. However, I had to explicitly set max-logins on boot to 32 (option -l), otherwise it would be set 64 but sc seems to accept 32 at max.
And even better: I’ve been able to set the hardware-buffer-size (option -Z) to 64 which I think matters for low latency. I’m using a RME Hammerfal HDSP soundcard which allows for extraordinary low latencies. It’s pretty old and I’ve never been able to make use of low latencies using pipewire-jack (as described on the Debian Wiki), so I stayed on regular JACK (Pipewire running on top of JACK). Your solution doesn’t seem to have this problem which gives me hope that I can use my soundcard in a future without JACK.
All in all very promising…
I believe that jack-pipewire’s buffersize can be controlled with environment variables. That’s not ideal (and I haven’t tested it), but it should work. I thought I’d point it as I didn’t see this being discussed before.
My thought was that, if sclang isn’t in control of the server’s boot process, then it doesn’t know which port the server is listening to. I do see your point, that one could make an assumption about the default port.
Current logic in sclang is that it does not look for any servers, except when it’s actively booting a server – s.boot tells sclang that a server should be running soon, so it starts polling at that time. Otherwise, if it’s idle, then it remains idle.
I guess if one wanted to poll the default server’s port at startup, one could create a remote server in the startup file (and delete the remote server if the default server is booted, perhaps using ServerBoot). My gut feeling is that this should be optional.
