Jack Audio Multi Client Support

[ghost]

Hello,

these fixes add support for Jack "multi client" mode. By multi client I mean allowing to create multiple clients who connect to different servers from one process.

In current Jack version this would result in overwriting synchronization and signalling primitives of shared memory. Each created client would overwrite client before, so that previous client would not be able to accept process and other callbacks and notify server of graph competition.

The patch introduces "global context" reference that holds instance of global and shared memory variables for each created client. This global context reference is then passed to all objects who require it.

Please note this PR disables functionality of metadata - this area is still under development and requires some architectural decisions on how to pass the global pointer to metadata.

Attached c++ test application can be used to verify this use case.

#include <stdint.h>
#include <stdbool.h>
#include <jack/jack.h>
#include <iostream>
#include <signal.h>
#include <unistd.h>
#include <string>

#define CLIENTS_NUM 8
#define PORTS_NUM 2

static jack_client_t* clients[CLIENTS_NUM] = {0};
static jack_port_t* ports[CLIENTS_NUM][PORTS_NUM] = {{0}};

char servers[CLIENTS_NUM][32] = {
	"acoustic", "acoustic", "acoustic", "acoustic",
	"media", "media", "media", "media",
};

static int backend_jack_process (const jack_nframes_t nframes, void *arg)
{
	return 0;
}

int main()
{
	jack_status_t status;
	jack_options_t options = (jack_options_t) (JackNoStartServer | JackServerName);
	const unsigned long flags = JackPortIsOutput;

	for (int i = 0; i < CLIENTS_NUM; ++i)
	{
		clients[i] = jack_client_open("client_name", options, &status, servers[i]);
		jack_set_process_callback(clients[i], backend_jack_process, nullptr);

		for (int j = 0; j < PORTS_NUM; ++j)
		{
			std::string portname = "port";
			portname += std::to_string(j);
			ports[i][j] = jack_port_register(clients[i], portname.c_str(),
				JACK_DEFAULT_AUDIO_TYPE, flags, 0);
		}

		jack_activate(clients[i]);
	}

	usleep(6000000);
	
	for (int i = 0; i < CLIENTS_NUM; ++i)
	{
		jack_deactivate(clients[i]);
		jack_client_close(clients[i]);
	}

	return 0;
}

On version before error messages can be seen:

JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = client_name was not finished, state = Triggered
JackEngine::XRun: client = client_name-01 was not finished, state = Triggered
JackEngine::XRun: client = client_name-02 was not finished, state = Triggered
JackEngine::XRun: client = client_name-03 was not finished, state = Triggered

Patched version does not have these errors and audio is correctly routed between multiple clients and servers.

Verification of changes is done on:

• qnx platform
• aarch64 platform

Adam

[falkTX]

I am sorry, but I am not going to merge this.
You can keep the PR open for anyone interested on it, but I would not want it part of the JACK project.

Let me explain...
It is first time I see ever someone suggesting such a thing - multiple jack servers for a single process. You went even further and actually implemented the whole thing. Very impressive!
But... even for the "jack server under multiple users" scenario, that is already not very well supported (due to lack of interest or users requesting it). Your approach is even less requested.

What is the usecase here?

I see some useful commits there, I can cherry-pick those so your diff ends up smaller.

[ghost]

Hi Filipe, thank you for having a look. If any commits get merged that's already fine and helping us to maintain with less effort.

As for the use case, we are running multiple instances of jack server (different sample rate requirements + no re-sampling constraint + effort to reduce cpu load). On top of that we are running a virtualization host that spawns an initialization process for guest OS, in this process we are connecting to multiple jack servers. As there is only one process spawned during the initialization of guest OS we have to make sure the static objects are correctly shared.

From architectural/requirements point of view it has to go this way for us therefore this change request came to be.

[twischer-adit]

This PR can be closed. It is replaced by #597