Implementing Dual Mono-in/Stereo-out, Multi-Channel fader

[dcorson-ticino-com]

I have looked closer at an implementation of multi-channel, or as I am now calling it Dual Mono-in/Stereo-out.
We have two different suggestions as to how to do this, either adding phantom clients with the existing UI or changing the mixerboard to display Dual Mono clients. The signal mixing, etc. necessary stays the same, the problems are around how to get the mixing info for the second channel from the client to the server.

Advantages of phantom clients:

• no need to change the protocol
• the well known UI remains unchanged
• old clients will work

Disadvantages of phantom clients:

• for the server the phantoms are clients and use an additional user for each (getting around this
  by doubling the max clients (as there is no additional bandwidth and minimal added processor
  power needed) hits a wall at 127 real users as Client IDs are only 8 bit)

Advantages of new mixerboard UI:

• UI will be cleaner
• does not add to number of users

Disadvantages of new mixerboard UI:

• protocol changes are necessary as each client will need to send 2 volumes, 2 pans, etc.
• protocol change to tell mixerboard if a client is "normal stereo" or dual mono.
• the server will have to query all clients as to their version, store the versions and use
  the corresponding protocol.
• An older client can play/display a dual mono user as stereo, but not manipulate it correctly

One problem that both have is that there is now no way to inform the server if client data is to be interpreted other than mono or stereo. My present hack is to tell the server there are 3 channels which it is to interpret as dual mono. Of course as the new mixerboard UI already changes the protocol...
Both also need additions to the setup, of course.

For me which to choose is sort of a toss-off. What do you think?
Is a limit at 127 users really limiting (of course it may be possible to add users only for the clients really using Dual Mono, but I haven't really thought that list management through yet)? Is the added user interface clarity worth the additional complexity of supporting 2 protocols ?

[gilgongo]

Can you give an example of how the mixerboard UI would look?

[dcorson-ticino-com]

Maybe something like this: (not mine)
#1840 (reply in thread)

[frenrude]

Thank you so much for this progress !
I would prefer the phantom users, since it seems to permit immediate or future extension to more than two channels per client.

[softins]

Just a few random thoughts on this...

I think phantom clients is the only realistic way to go. It provides maximum compatibility with existing servers and clients, which will just see two channels.

If we can find a backward-compatible way to notify the other clients that the two channels are a pair, then a new client that understands this could optionally display the two channels as a pair, but this is not essential.

It will be necessary in the "My Profile" setup to allow the user to specify two instruments and skill levels, one for each input channel.

By using phantom clients, it is not actually necessary for the clients to be mono. For an interface with more than two channels, it could provide stereo client signals. For example, on my UMC404HD, I have a mic on channel 1 and a piano in stereo on channels 3 and 4. Currently, I have Jamulus input 1 as channels 1+3 and input 2 as channels 1+4, so the piano is stereo and the mic is centred.

Another consideration is that the server will be sending an audio feed to both phantom clients, although only one is required. So the new client will only want to output one of them to the audio hardware.

It would be good if it were possible to have unidirectional client connections, then a listener could have a receive-only connection, and a phantom client could have a send-only connection. Receive-only connections are not possible while connections are still defined as the presence of an audio stream, rather than by a control protocol.

[dcorson-ticino-com]

Hi Tony,
Hope you had a good vacation.
I have just pushed my first draft of this, am presently compiling for ARM and will put it on my public server Classical>Strings Server later this evening, I hope.
I have implemented so that the phantom clients are really never connected, the server expects no sound data and also doesn't send sound data to the phantoms. They are only used to transfer the fader position, etc.

I have not had an idea how to send two names and two instruments from a single client without changing the protocol, but as that would just be between the client with dual mono input and the server I could add that without cutting out the older clients as receivers.

For me next up is to get this running for delay panning. On my first run through that code I didn't understand how it works, so I may need help.

I'm on vacation from the end of the week, will get back on this after.

[WolfganP]

Another consideration is that the server will be sending an audio feed to both phantom clients, although only one is required. So the new client will only want to output one of them to the audio hardware.

It would be good if it were possible to have unidirectional client connections, then a listener could have a receive-only connection, and a phantom client could have a send-only connection. Receive-only connections are not possible while connections are still defined as the presence of an audio stream, rather than by a control protocol.

Completely agree. If the path to multichannel is phantom clients, then it's important that the server is being impacted as less as possible, so saving on unnecessary mixes for the phantom clients is a must.
Probably the discussions on Director mixes could be leveraged to make this feature a complementary one, departing from the default of 1 individual mix per client processing.

[dcorson-ticino-com]

I have implemented so that the phantom clients are really never connected, the server expects no sound data and also doesn't send sound data to the phantoms. They are only used to transfer the fader position, etc.

If the path to multichannel is phantom clients, then it's important that the server is being impacted as less as possible, so saving on unnecessary mixes for the phantom clients is a must.

As I wrote, in this implementation the phantom clients niether send nor receive sound data.