At about 70 client connections the client/server do not show/list all clients anymore

[corrados]

See the report in this post: https://github.com/corrados/jamulus/issues/455#issuecomment-681572514

[maallyn]

Tony: I agree that large choirs should wait for V4. Considering that, could this ticket be a candidate for V4 and not the current Jamulus? It seems to me that the current use case (jams of small groups) is currently supported well (witness the World Jam) where we have about 40 people max at once (in the waiting rooms) with no problem.

[storeilly]

Maybe for a choir kind of usage, we need some kind of architecture where there is a generic mix produced, that can be controlled by one person, but that is then sent identically to most of the clients. That would reduce both the mixing load and the technical usability burden on those users. There could still also be clients that have their own custom mix.

But these would be ideas for Jamulus V4.

Even large choirs will need to mix their individual with the "supplied" mix so does that still need n * n mixes? I've been under pressure and haven't had time to contribute to this for the last two weeks, but I am still very much engaged. I don't think we've figured out why the system creaks yet without peaking on the CPU's or network.! I don't think the choirs can wait for V4. My one can't anyhow, we will make something work. Please don't drop this!

[maallyn]

I was thinking about a setup where the mix would be done by the choir director. He or she would have the 'normal' Jamulus client with all of the faders. Then, each choir member would have a simple client with just a master volume control. In fact it could be 'pre-provisioned' such that it would 'know' which server to connect to, which would be even better for those choir members who are afraid of technology. There are some in my two choirs who are almost afraid just to turn the computer on. In addition, since on the choir master would have the mix panel, there would be mix related traffic for that one alone, which I hope would mitigate the issue of too much traffic handled by the server.

[corrados]

I don't think the choirs can wait for V4. My one can't anyhow, we will make something work.

Have you tried a fast server hardware with Jamulus multithreading enabled and all musicians use Mono mode? If the musicians do not connect all at the same time (which is usually not that case), the protocol traffic should be low enough for a session even if a lot of clients are connected.

[corrados]

Maybe for a choir kind of usage, we need some kind of architecture where there is a generic mix produced, that can be controlled by one person, but that is then sent identically to most of the clients.

Jamulus uses different modes like the "Small network buffers" and "Mono/Stereo". To keep such a proposed implementation simple, would it be an option that in your new mode only large buffers (128) and Mono is allowed? That would make the implementation easier so that the one master client only has to generate and store just one block of OPUS coded audio data.

[kraney]

I'd just like to chime in that I'm similarly trying to get this going for high school bands during COVID restrictions, and I also would benefit from being able to have a "director-controlled" mix, with all clients receiving the same mix. That potentially eliminates the n^2 problem as well as simplifying the user interface for those that don't need a mix, and possibly reducing the amount of info each client needs to get about the other channels, so smaller messages.

I'm hoping to be able to contribute some help, but I'm just ramping up on the code so I don't have a ton to offer yet.

Just to brainstorm a possible approach, possibly there could be two server UDP ports. One is a "director" port and functions as today. The other is a "member" port and which is included in the mix but simply gets back a replica copy of one of the "director" mixes, verbatim. No custom mix if you're connected on the member port. If more than one person has joined via the director port, possibly a member could select which of those mixes they use. Number of directors could be limited to the old max, like 15 or 20 or whatever, while members could go much higher.

Another option would be to just have one person be the director, and maybe let that person "pass the baton" (if they choose) to a different person, who then becomes the one-and-only director. Everyone else just gets a replica mix. Or you could password-protect the director port. But these options diverge further from the existing mode.

In my case at least, locking to 128-byte buffers would most likely be acceptable. I favor Mono-in/Stereo-out I think, if I understand its function correctly (so that members can be given separation across left-to-right by the director,) but the specific mode would not be a dealbreaker in any case.

[kraney]

I ran some tests with 40 clients which worked fine, but adding even a few more caused issues with the last clients having no name information and poor audio. It was a pretty predictable line at 40, which led me to suspect it was adding a 3rd thread that caused issues. Also doing math on the ConnClientsList message, that's right around where it would reach MTU size for the packet.

One plausible hypothesis on why you're seeing failure start at different numbers of clients - @maallyn you are setting client names, right? @corrados are you? That message is variable length so having longer client names would get that message to MTU faster. At least in my case I don't think fragments will survive the journey.

[corrados]

Just to brainstorm a possible approach, possibly there could be two server UDP ports. One is a "director" port and functions as today.

I do not want to make big changes to Jamulus to support this. Here is my specification which will be quite easy to implement, just adding a new command line argument to the server like --singlemix:

• No multithreading (since we only have one encoding and mixing so no multithreading needed)
• Only 128 sample frame size support
• Only Mono support (gives us the most possible number of connected clients which is what this modification is all about)
• The first connected client on that server is the "director", all other clients which connect afterwards get his mix. So you just have to make sure that the director is already connecting to the server before your session begins (this requirement should be very easily to be fulfilled).

There is a vecvecbyCodedData buffer which is used for both, encoding and decoding. I'll introduce a separate buffer so that I can re-use the output buffer of the first client for all other clients. So instead of calling MixEncodeTransmitData for all the other clients, they simply get vecChannels[iCurChanID].PrepAndSendPacket ( &Socket, vecvecbyCodedData[iDirectorID], iCeltNumCodedBytes );. I just did a quick hack: If I modify CreateChannelList so that no client is added, the audio mixer panel is just empty. This would be the case for the slave clients. But then they do not see how many clients are currently connected which is not a big issue. If "--singlemix" is given, "-F" and "-T" is deactivated and a warning is shown that these cannot be combined. In the OnNetTranspPropsReceived function we can check that the client uses 128 samples, if not, refuse to connect.

[corrados]

I just created a new branch for this: https://github.com/corrados/jamulus/tree/feature_singlemixserver

[corrados]

I just created a new Issue for that: https://github.com/corrados/jamulus/issues/599

[corrados]

@kraney You can start testing now. The current version of the code does not implement any checks for correct client settings. So you have to make sure:

• all clients use mono and also the same quality setting, e.g. "normal"

All clients see the full mixer panel but only the first connected client actually controls the mix. If the other clients move the faders, nothing will happen in the audio mix.

Have fun :-). Feedback welcome.

[corrados]

I'll close this Issue now since the original issue caused by UDP packet drops should be solved by the "split protocol messages" fix which is already implemented. The discussion about the singlemix server should be continued in the new Issue I created.

[maallyn]

Just to let you know, now that this is closed, I went ahead and destroyed my test server client.allyn.com