Jamulus for a choir (20 to 30 people)

[dawind]

Good evening,
thank you for providing such a great software.

Currently, we use Jamulus as a choir of 20 to 30 people.
With an increased number of participants, we have some kind of loud noise (jitter?) that disappears, if you reconnect to the server or if you reset the buffer (even to the same value e.g. 2.67ms). Simultaneously with this noise the server side buffer seems to increase dramatically and decrease afterwards. After that, the noise did not disappear at all.

We tested without all participants with an unstable ping time (more than +/-5 ms) to the server, but this doesn't really improve the situation.

Therefore, I've the following questions:

• What is the best way to debug / improve this setup to get a more stable audio mixture for all participants?
• Is there a way on the server side to increase the network buffer for all participants to mitigate such issues?

Our current setup:
Jamulus version: 3.6.2 (server and clients)

Server setup:
OS: Debian
Running Jamulus as a service: rt with nice=-20
Params: -F -s -n -T -u 50 -w xxx -R xxx /
Server Hardware: 4 x 4,5 GHz / 32 GB DDR4 ECC / 1 GBit / s connection

Connecting to the server via ssh, I don't see any hints that the server reaches any capacity limits as it only uses one to two threads and about 50 MB RAM.

Clients:
Mainly windows or Mac clients with connecting via ethernet and a large variety of microphones and headphones.

[dcorson-ticino-com]

This is most certainly an Internet connectivity problem of your server.
Is your server on the cloud or local to you?
Have you tried other servers with a good ping time for you?
Your hardware is certainly able to run 20 to 30 users.
To run well we need an Internet connection that is not only fast enough, this is usually no problem, but also that regularly transfers the data packets. Noise happens when packets get lost or are delivered too late or in clumps. The jitter buffers can help, and the packet reordering that was recently added to Jamulus has made a big difference. But there are limits to what is possible to correct when the connection gets flaky. Resetting the buffer stops the connection for a short time, clearing any mess that may be there, but as you have seen, it is not a solution.

[dawind]

Thank you for your reply.
The server is on the cloud as dedicated hardware and has a good ping time (5ms). That is basically why I choose this provider :). I'll try another one later on.

Could I treat this kind of problem isolated for each client-server combination or does one client buffer disorder affects other clients?

Does Jamulus write any logs (client or server), if the packages get too disordered?
It would be helpful to have something to clarify the current connection problems with the provider.

[dcorson-ticino-com]

Could I treat this kind of problem isolated for each client-server combination or does one client buffer disorder affects other clients?

You need to imagine how the data flows. A problem in the upstream connection from one client to the server will be heard by everyone as the mixing is done on the server. A problem in the downstream connection from the server to a client will only be heard by that client.

Jamulus is written "lean and mean" to be able to pull the maximum of audio quality from the existing connections. There is no time or data wasted on non-audio processing such as logging or statistics, however helpful that would be in some circumstances.

The problem is that we need a specific type of performance from the network that just about no-one else needs. The providers do not have such performance needs on their screen. We do not need a lot of bandwidth (except maybe at the server) but regularity, low jitter, which no-one cares the tiniest bit about. Some people have reported that by going to a more expensive plan at their provider they have had better results, not because they needed the processing power, but as they then apparently had better connections. See if you can try it out. I agree, 5ms ping is nothing to be coughed at.

[dawind]

Thank you for your explanations.
I looked at the client side incoming and server side outgoing packets using wireshark and tcpdump respectively and calculated the difference between consecutive packets. There were some spikes upwards which seem to be responsible for the noise. I'll try if the provider could help to improve the routing.

[gene96817]

What are the ranges of your interpacket delay? If you have the time, delay by min, mean, max, and std. dev. would be very interesting,

[mhilpolt]

If you still have that kind of problems, I can offer to try a rehearsal on my server, where I have not observed that kind of artifacts. I'm using that server for a chorus with regular rehearsals of 30 - 35 singers. The server is located in Frankfurt, is a dedicated machine with a real low profile, but the load is far below 50%. Maybe that helps to localize the root cause.