Emacs, pipewire and sc

Questions
1

Hi,

I am running on Debian testing and usually run scide via pw-jack so that pipewire is used as a jack-replacement.

Now I would like to setup emacs for that as well but I am failing…

What currently happens is that when I run “M-x sclang-start” in emacs a supercollider-process is started which in turn seems to start a jack-process, which is not what I want.

I have tried to fiddle with customization-variables to make emacs not use “sclang” but “pw-jack sclang” and have tried to supply a shell-script instead but I could not get it to work.

It probably does not help that I know very little about emacs or supercollider or pipewire…

Does anybody know how to do that?

2

sclang is the language, which shouldn’t be starting a JACK process.

I just tried sclang-start on my machine and there’s no audio involvement at that point.

One possible cause is, maybe you have a startup.scd that boots the server? IMO it’s not a good idea to auto-boot the server, because you might want to do something to the configuration before booting. So I’d recommend to check your startup file and remove any s.boot from there.

To use pipewire in SC, I think you should modify the Server’s “program” command before booting:

Server.program = "pw-jack scsynth";
s.boot;

hjh

3

Many thanks, that seems to do the trick.

What seems to be happening without your setting is this:

To use supercollider from emacs you run “M-x sclang-start” which starts an sclang process with which emacs communicates.

If you then boot the server (s.boot) an scsynth process is started which does something that makes systemd start a jack-process.

But setting Server.program works.

4

If a JACK server is already running at the time of booting the SC server, then scsynth will not launch a new JACK server – it will connect to the existing one. In non-pipewire systems, this is typically recommended.

If there isn’t a JACK server running, SC will start a JACK process (but I believe you don’t have full control over connections to other JACK apps this way, which is why we generally recommend starting JACK before running SC).

pw-jack should spoof a JACK process environment to which scsynth should be able to connect.

hjh

5

In an ideal world sc would be able to recognize a pipewire-instance and connect to that on it’s own rather then having to be fooled into believing there is a jack-instance to connect to.

But Is pipewire nowadays ready to replace jack for more demanding work or do you still prefer jack?
I mainly want to use pipewire because in this way I can use my bluetooth earplugs to listen to the sound that comes from supercollider…

6

I think someone did start work on a native pipewire backend for scsynth, but it’s more complex than you might have thought, because it also needed to replace the whole scsynth audio framework with (I think, maybe my memory is faulty) RtAudio and this was problematic for a number of reasons, so it wasn’t finished. It should still exist as a pull request if you have the C++ chops to finish it :wink:

In any case, pw-jack seems to be meant to help developers of JACK audio apps avoid the work of implementing a separate audio framework just for pipewire support.

I asked this question elsewhere and got mixed replies. My general impression is that pipewire is fine for relatively simple use cases (like stereo output from SC) but not ready, for instance, for large-scale multichannel studio recording (where JACK is already a proven technology).

I do hear that extremely low latency use is possible in JACK and not necessarily possible to the same degree in pipewire. (But you’ll never get super low latency with your Bluetooth earpieces anyway, so this is likely not a concern for you.)

hjh