Create send and receive jack ports for each channel on server

[mikedickey]

As the owner of a Jamulus server, I would like to be able to use external software applications for audio processing (recording/mixing/etc), by leveraging the Jack Audio Toolkit ("Jack").

A Jamulus server currently mixes all audio internally, making it difficult or impossible to use alongside other software applications running on the server. Some examples of these are:

• Digital Audio Workstations (DAWs)
• SuperCollider
• Carla
• PD
• etc.

Jack is a very popular framework used to efficiently share low-latency audio across software applications (especially on Linux, although it is also available for Windows and Mac OS X). Jamulus clients on Linux currently use Jack to integrate with system audio devices. When Jamulus is run as a server, it does not currently open or use any ports in Jack.

I would like support for an additional command line option (let's maybe call it "--jackports"?) on servers (Linux only headless is fine) that causes Jamulus to:

• create "receive" ports for each audio channel being sent from each connected client (i.e. "Jamulus:receive_1" and "Jamulus:receive_2")
• create "send" ports for each audio channel being sent to each connected client (i.e. "Jamulus:send_1" and "Jamulus:send_2")

Audio received over the Internet from clients would only be delivered by Jamulus to the "receive" jack ports, and only the audio being received on the "send" jack ports would be delivered over the Internet to Jamulus clients. When running in this mode, the Jamulus server would not perform any audio mixing itself.

[mikedickey]

Please forgive me if this is the wrong process for this, but I am offering a $1000 bounty for this feature here: https://www.bountysource.com/issues/100519769-create-send-and-receive-jack-ports-for-each-channel-on-server

[ann0see]

Hmm. Tagging @dcorson-ticino-com @jujudusud and @henkdegroot here. As far as I know, they’re into JACK…

Concerning your idea: I doubt it’s easy to implement, but who knows?

Before starting to work on it, everyone:
keep in mind that you should still follow the KISS principle

[jp8]

I am interested to know what it would be used for. We had a similar request in the past, which was to have the mix for 'streamer' clients show up as a jack output (for high quality streaming).

But this request.... I don't understand what the use case is.

[dcorson-ticino-com]

If the Jamulus server does no mixing, then I assume there will be XX instances of some other SW on the Jamulus server's machine doing the mixing for XX clients. But how will the clients send their fader info to the processing SW instances ?
IMHO this suggestion tries to get Jamulus to do something that it was not made to do and doesn't have the structure to do either.

Note that I sometimes use Jack, but I am in no way invested in it or understand it.

[npostavs]

IMHO this suggestion tries to get Jamulus to do something that it was not made to do and doesn't have the structure to do either.

Yeah, why not use JackTrip instead?

[mikedickey]

My primary motivation for this is bridging JackTrip & Jamulus users with SuperCollider acting as the audio processing/mixing engine. JackTrip Labs does this today via on-demand cloud audio servers ("virtual studios"), which are currently free at 53 locations worldwide. You can configure them to run "JackTrip" or "Jamulus" or "JackTrip+Jamulus" audio servers.

The current implementation for "JackTrip+Jamulus" runs both a Jamulus server and Jamulus client on the same machine. The client's only purpose is to essentially create two jack ports for the stereo Jamulus mix. We then auto-patch everything into SuperCollider, which handles all the mixing. The obvious downside is that it's just a simple bridge of the stereo mix. We can't provide the same level of experience/functionality (leveraging SC) that we can for JackTrip users.

I do believe there are other use cases for this feature such as recording, streaming, etc. Jack is quite popular, so it would open Jamulus up to integration with many other applications. But I agree it's a very advanced use case that 99% of Jamulus server operators would likely never use. That is why we're offering a bounty for someone to build it, in hopes that it would not be a huge or disruptive effort, and additive overall to the open source project.

[jp8]

So if I understand correctly, you are using the SuperCollider software synth as a digital mixer in the cloud, and you'd like to integrate it with a Jamulus server so that Jamulus clients appear as individual channels in your SuperCollider mixer.

I can see that this proposal would make Jamulus clients show as separate channels in the SuperCollider mixer. But the Jamulus users would be seeing the Jamulus server as their mixer. Would the native SuperCollider (Jacktrip?) clients also appear as individual channels in the Jamulus mixer ?

What is the license on your plug-in mixer add-on for SuperCollider ? Maybe a tighter integration is possible.

[mikedickey]

Sounds about right. I understand that the Jamulus client mixer would not work for this approach. Our SuperCollider code is Apache 2.0 licensed, see https://github.com/jacktrip/jacktrip-sc/tree/develop

[mikedickey]

BountySource seems to be having issues, but i just wanted to note that JackTrip Labs is willing to contract with someone to build this and we’re upping the offer to $5,000 (USD). All work will be donated back to the community as open source, for inclusion back into the jamulus project as an extra feature, or just as a standalone fork if that is not desired.