Options for running Ardour on remote server

I am working on creating an online rehearsal/jamming space for a group I play in (due to the pandemic). I have set up a Jacktrip server on AWS and connected the participants by way of QJacktrip (a graphical interface available on Windows for jacktrip). In our physical workflow, we were used to having one of us mixing our instruments and voices on a mixer, and I am trying to replicate that mode of operation for the online rehearsal space. We have learned that we need it even more for the online space, as Jack+Asio4All on Windows often leaves participants on integrated audio without a way to adjust their volume (most common problem is that it is too low).

I have experimented with ecasound, until tests revealed that it is not multicore and thus would not scale well, and I am aware that some folks have set this kind of mixing using SuperCollider. However, either approach does not give us the flexibility inherent in having someone just operating a DAW.

I am familiar with DAWs, and since Ardour is built with Jack in mind, it seems ideal for mixing, adding effects, etc., to a bunch of Jacktrip participants. However, I am not sure how to proceed and would welcome your thoughts and recommendations! Here are some ideas we are currently entertaining:

  • The first approach that comes to mind is running Ardour on the server and using X-forwarding or some other remote desktop technology to use the GUI. It has the disadvantage that server resources are wasted running the GUI.
  • The second approach would be having Ardour running headless in some way, and controlling it remotely. I have found some not entirely conclusive threads on whether this could be done. Is it possible to run Ardour headless? If yes, how would one go about controlling it? Is there any way to run the full GUI on a client machine, or would the interaction have to be programmed over OSC or Web-sockets? If the latter, are there any full-featured control clients available?
  • It would be ideal to have a base setup, with a full mix and personal mixes for each participant, available from the get-go. Would this be possible using an Ardour project, given that Jacktrip clients may come and go during the session? Would a scripting approach using Lua be more appropriate?

At this time we are exploring available options, so any ideas are welcome!

Ardour can be built to run headless. We do not distribute a build that includes this version of the program, but if you build it yourself, it will be created and installed.

You cannot run “the full GUI” on a separate machine. You can use OSC or the still-experimental WebUI to control the headless instance, along with MIDI based protocols.

1 Like

Thank you for the reply - building will not be a problem. Everything else in this project had already to be built from source as I am running on an AWS ARM instance and most of the software for the project on Ubuntu’s repos is outdated.

The Web UI that you referred covers the same functionality as the normal GUI, or only a subset of features? I will perhaps start by trying that out.

The WebUI is still experimental, but has access to everything that OSC has access to (because it is built on top of our OSC support - basically OSC-via-websocket). What is actually presented on the pages that we already offer is fairly limited, but it’s all completely modifiable without rebuilding.


I don’t believe that regular editing GUIs can be built using a protocol like OSC, mostly because of the problems with displaying waveforms. But I’ve been wrong before in my under-estimation of what modern computers can/could do. However, everything related to mixing should be accessible.

Also custom plugin UIs won’t be available when you use the websocket control surface.

The most reliable way is to run Ardour on the remote system (ideally even with graphics acceleration three) and then use VNC (this usually performs better than remote X with gfx acceleration on the remote machine, and also allows to easily dis/re-connect)

PS. see also Headless Mixbus

Yes. you could either start it and then control it via OSC or websocket, but a more powerful way is to use the interactive Lua shell. That also offers edit operations on the timeline.
arodur6-lua comes with ardour.

Some references:

With your indications, I have just completed the first part - compiling Ardour 6.6 on the remote server and running Ardour headless (hardev) and the web server control surface. Most dependencies were available with suitable versions on the Ubuntu Focal repositories, except for gnome-doc-utils, jpegsrc, lv2 and libwebsockets, which I had to build from source. The latter in particular required enabling LWS_WITH_GLIB and LWS_WITH_EXTERNAL_POLL before building.

In order to enable the Web Server Control Surface without setting it in the GUI, I took some time reading through Ardour’s source code to find that I could do it editing the Ardour session (*.ardour) XML file. In hindsight it was kind of obvious.

So now I have a mixer on my browser, that I can use to control Ardour on the remote server. For the next step I will try to automate creating the base timeline from the jacktrip clients using ardour6-lua as recommended.

1 Like

If you do not need to change the session-layout (tracks busses etc) on the fly, you could also get away with template sessions, or tinker with the XML and re-load the session.

If you do need interaction, I suggest to run ardour6-lua in a screen(1) or tmux(1) on the remote server (just in case you don’t know those tools already). That allows to keep it running and re-attach to the interpreter at any later time.