Question: Does one person with bad ping/latency ruin it for everybody?

[DominikSchaller]

The question came up on Facebook and at our own rehearsal, and I was not able to answer it.

Does the server do some kind of synchronization based on the ping/latency of all clients? Like is the worst latency the common denominator? Or does the server just collect all inputs in fixed cycles and sends the mix back (independent of the clients)?

And if it has an influence, I have a special case follow-up question: If we have a guy with a bad connection and he is muted, does that have influence on the overall latency?

[hoffie]

Does the server do some kind of synchronization based on the ping/latency of all clients?

No, I don't think so.

Or does the server just collect all inputs in fixed cycles and sends the mix back (independent of the clients)?

Yes, that's my understanding. The server runs a (tight) loop which collects audio data for each client/channel:
https://github.com/corrados/jamulus/blob/master/src/server.cpp#L423
https://github.com/corrados/jamulus/blob/master/src/server.cpp#L782

So, a slow/bad connection should not break a Jamulus server. It might ruin the experience musically for other users due to cracks, clicks or delays unless everyone mutes the problematic client.

If you have evidence that a slow client does indeed cause technical troubles for everyone, I'm pretty sure it would be interesting to track down such cases (I think someone mentioned something like this in the past, but I cannot find the place).

[pljones]

One player not listening only to the mix can be playing out of sync without knowing and that will cause everyone else to start trying to allow for them and you'll get a "cascading" effect.

[gene96817]

@hoffie I believe our sessions at HI-Studio1 is experiencing this behavior when a person with >150ms joined. The aberration affected all users. Having everyone mute this person did not resolve the problem. Normal behavior was established after the visitor disconnected. I believe this has been observed in two different weeks.

What information do you want to collect?

[pljones]

WorldJam weekly concerts have have people playing together with over 100ms between some players and the server -- I'm not sure if it's as much as 150ms ping. The overall delay might be that high, I'm not sure.

Did the new joiner state their ping and overall latency figures?

[gene96817]

Curious. I will confirm. Assuming the delays are symmetric, my delay to a server in that local is >100ms. I will confirm the details for the next occurances.

[pljones]

Please quote both "Ping Time" and "Overall Delay" figures from the Jamulus Settings panel - without both, any figure isn't particularly useful.

What do you mean by "symmetric"?

For "Ping Time", your client sends a packet to the server with "now" on it, the server returns a packet with that original timestamp on it and your client determines how long it took. "Overall Delay" takes into account how much extra delay the displayed buffer sizes add to the ping time.

[gene96817]

If we assume transit times are relatively symmetric, then I can get an estimate of ping and overall delay from what I see for a server near the user.

[pljones]

If we assume transit times are relatively symmetric, then I can get an estimate of ping and overall delay from what I see for a server near the user.

What do you mean by "symmetric"?

Knowing transit times from A to B gives you no indication of transit times from C to B. Just because your routing ("from A") to a server ("B") is good, has no bearing on whether some other user's routing ("from C") to that same server is also good. Or bad.

Only knowing both the "Ping Time" and "Overall Delay" figures shown in Jamulus can provide diagnostic information.

[gene96817]

Yes, I know that. But getting some rough data is better than none. If nothing else, it could help rule out some hypothesises.

[hoffie]

What information do you want to collect?

Besides what @pljones already said, the following details may be worth collecting: Jamulus server/client versions, number of users, server options (--multithreading, --fastupdate), client options (buffer sizes, small network buffers, etc.).
The simple fact that such an issue is reproducible (is it?) in your environment may be also interesting. Any detail helps for some developer to reproduce and debug it. To simulate high ping times, tc can be used under Linux, for example.

[gene96817]

This is going to be tricky interrupting a rehearsal to collect all these details from 10-20 participants. Some of the participants are nervous about technology.

My plan will be to first see if this condition will appear with under 10 participants. Then collect ping times, overall delay, and client versions when it happens. Hopefully, I will end up with participants that can help provide the other details.

[ann0see]

I converted this to a discussion now since this is not an issue.

[chrisrimple]

I've played many times with musicians having Overall Delay of 20-100ms, and the addition of new high-latency clients to the server has no impact. During a jam session yesterday, clients connected from the other side of the world (with Overall Delay of 200ms+) and there was no change for the musicians already on the server.

I think those that are reporting this as an issue are actually seeing two things:

• A new client joins the server and that client has high jitter, resulting in "burble" in their sound that "ruins the mix for everyone". This can be solved by (1) having that client resolve their jitter problems and/or (2) muting that client.
• A new client with high Overall Delay joins the server and attempts to play in synchronization with others, but starts falling behind. Other musicians hear the delayed client, try to adjust, and also fall behind. This can be solved by (1) having all clients listen to and follow the drummer (which often includes increasing the drummer's fader in the individual client mix), (2) ensure that the drummer is keeping time and ignoring the tempo of the other musicians (which may include playing to a visual metronome - free mobile apps are available), and (3) if there is no drummer the musicians have selected another musician to keep tempo and for everyone to follow.

I don't think there's any engineering work for the client or server required.