Running Carla as a Systemd service

[kawazoe]

I use EasyEffects for some microphone processing, but I find their platform and UI very limited. I really like how Carla tries to act more like a DAW in that regard and give you full control over plugins, with access to their UI, and a much better ability to manage how audio is patched through. I'm also very interested in its midi capabilities to remote control some parameters with a MIDI controller.

I know that Carla already supports running in headless mode, and with the OSC version, can connect to that instance over the network (which conveniently includes localhost).

I wish there was a one click solution to create a systemd service that would:

• setup the current project to be run in headless mode,
• with either a custom prefix or a prefix based on the project name,
• with the proper error handling to restart the process when a crash happens,
• and dependencies so that it starts after the audio sub-system is initialized (like after the pipewire/wireplumber services).

I'm currently trying to design the service file, so I might have a template for it soon here, but I would really like if this could be integrated directly into Carla. I just wish I didn't had to think about managing the file myself if I ever want to setup a second pipeline for other reasons.

[kawazoe]

After fiddling a bit around this problem, there are a lot of hurdles that makes this surprisingly difficult to do by hand.

Preparations

Create a services folder inside /usr/share/carla and make sure it is owned by the root user and a group all users are in, and you have write permissions. For me, I used realtime since it is recommended to get pipewire working optimally. This needs to be done as root.

sudo mkdir /usr/share/carla/services
sudo chown root:realtime /usr/share/carla/services
sudo chmod -R u=rwx,g=rw,a=r /usr/share/carla/services

Project

Create a Carla project. You can always come back and edit it later, but for now, we'll save the empty project in /usr/share/carla/services/<prefix>.carxp. We should be able to save and edit this file without any root privilege as our group has rw permissions. The <prefix> should be replaced with a simple description that you can quickly relate to the patch you are building. We will reuse it in many places. This can be "mic", "voip", or anything else that you'll recognize at a glance.

Use as a device

If you want to use your Carla patch like any other input/output device in your computer, for instance, as a microphone input for Discord, you will need to do some additional configuration at this time. Assuming you are running pipewire, you will want to define a custom loopback device that auto-connect to your carla instance.

TODO: document this part.

Service

Now that we have a project to run as a service. It's time to define the service in systemd.

[Unit]
Description=Carla - <prefix>
After=pipewire.service
BindsTo=pipewire.service
Wants=wireplumber.service

[Service]
Type=simple
Restart=always
ExecStart=/usr/bin/carla --no-gui --cnprefix=<prefix> /usr/share/carla/services/<prefix>.carxp

[Install]
WantedBy=graphical-session.target

You can save this service as /etc/systemd/user/carla-<prefix>.service.

Now, you can run:

systemctl daemon-reload
systemctl --user enable carla-<prefix>.service
systemctl --user start carla-<prefix>.service

Conclusion

And voila! You can do this with different prefixes for as many patches you want to run.

If you ever need to edit your patch, you can use Carla OSC to remotely connect to the service instance, though you might have to specify custom ports in ExecStart for each instance. You can also stop the service, open the project with carla by specifying the same cnprefix to ensure it connects to your virtual devices like the service does, make your changes, save, quit carl, and start the service again.

I might turn this into a script if people are interested.

[kawazoe]

@falkTX I guess you would need the pipewire-jack compatibility package for this to work, right? If that's the case then, there are a lot of advantages on using pipewire directly instead of the jack compatibility layer. Namely, pipewire's graph has authorization built-in, which might or might not matter to you. You also save on buffer copies as pipewire need to copy the stream buffer to support jack. Else, then I'm missing something. Pipewire streams cannot connect to other applications unless they are using a compatible API. This means that unless pipewire support has been added since I opened this thread, you can't connect to a pure pipewire stream from Carla without either pipewire-pulse or pipewire-jack installed. But then, you're not doing pipewire. You're doing pulse or jack.

[falkTX]

you need pipewire-jack indeed yes. and there is no point on trying to use pipewire apis directly since this jack mode works very well, and also allows people that do not use pipewire to keep using it in good old jack mode.
I have no intentions on doing a pipewire-specific backend, what we have through jack works well and is more compatible.

PS: the app name is carla not clara.

[kawazoe]

Oh yes of course. I don't think you should spend time explicitely supporting pipewire. I was just trying to explain how the Carla patchbay is different to pipewire, and what you just said confirmed my suspitions.

With that being said, I don't think that "jack works well and is more compatible" is a good argument to avoid supporting it. The pipewire FAQ goes very deep on why pipewire can be better than jack for some usecases. I think the biggest one for Carla relates to performance. It's faster than jack with similar latencies, which is good for audio production because it means less overhead, and it also supports dynamic latencies which is good for power constrained devices like laptops. They can be good reasons to want to support pipewire direcly, but only if your users needs those things. Until you get tons of people trying out setups like me and Xueran, who might benefit from running in dynamic latency mode, jack's definitely the way to go.

Nice chat though ❤️

PS: Oh wow, I didn't even noticed that I switched midway though the conversation. Fixed :)

[falkTX]

all is fine and good except

It's faster than jack with similar latencies, which is good for audio production because it means less overhead

is simply not true. pipewire has a lot more stuff to deal with, so "less overhead" is just not possible, and "faster" in this context I dont know what you mean.

[kawazoe]

I'm really just quoting their wiki here. They have benchmarks that demonstrates pipewire needs about half the CPU instructions to achieve the same kind of work than JACK would for a simple usecase like playback/recording without any kind of resampling.

But even if that would be wrong, it doesn't change that pipewire is a bit like the Wayland of audio. Every distro out there is slowly switching to pipewire. Some tools like Hyprland flatout requires it if you want to do screensharing. Over time, it's going to be harder and harder to find a system that won't already be runing pipewire, which means the JACK implementation you're connecting to will most likely be a compatibility layer on top of a pipewire node, like in the scenario we're discussing here. In the end, you'll have to pay the pipewire tax anyway so a JACK Carla audio system will always be less efficient than a pure pipewire one.

But again, like I said, it probably doesn't matter much, and for at least a decade people who want a pure JACK setup to run their DAW with the best performance will still be able to make a system without pipewire if they really wanted to.