Show member latency in mixer window

[FransFrijns]

I'm a music teacher and I use Jamulus for band lessons. I think it would be helpful to me if I could monitor each individual overall latency in the mixer window to help troubleshooting problems during sessions.
Is there an option possible to show both ping time and overall latency beneath each mixer channel?

[DominikSchaller]

There's also an issue for this in the backlog, @hoffie intends to work on it:
#961

[dcorson-ticino-com]

At the moment each client only knows its own ping and latency.
As far as I know the server does not measure this.
The server would have to collect this information and send it to all the clients meaning new protocol messages and increased bandwidth.
However useful this may be, I doubt that it will be happening soon.

[gene96817]

The server already collects the user profile and the user channel status. Are they two different data sets? Why cant the ping and latency be added to one of these? For instance, if it is part of the channel status (which includes the volume, mute, and group status) extending that to include ping and latency would not add significantly bandwidth load. It also does not require a new protocol. Further, the work is mostly in the client, so that should not be a burden on the server.

[dcorson-ticino-com]

The problem is not where to store the data in the server, but new messages must be defined.
They must then be treated as special cases by both the server and client.
Do the old servers and clients know what to do with messages they don't know?
The server does not know the ping or delay time of any client.
In this day-and-age the added bandwidth is maybe not too much, but it is there.
Doing this entails a big rats-tail of work and a large testing campaign.
Someone would have to feel a calling to do this work.
It seems like a tiny request, but it isn't

[DominikSchaller]

The question is, how often are the new stats sent? The profile name and channel status don't change frequently. Maybe the new stats can be sent once a second? I know that there are already some messages which are sent with such a frequency.

[WolfganP]

Instrumenting Jamulus to help users and admins troubleshoot any issues or improve performance is always a good move.
Collecting user states (ie latency obsrved, clips, queue lenghts, ...) is important, but I don't think that information should go back to the clients as it will complicate the UI and confuse non tech users. Keeping them in the server (logs, status pages, ???) will help the server admins/power users with access to manage the whole experience better and smooth the ride for everyone.

[gene96817]

There are a lot of sessions where the attendees do not have access to the server.
In my case, my server(s) are also intended to be a community resource. I am the only one with access to the server and I don't plan to be available for every session. We are discussing a very helpful tool and it needs to be helpful to a session without the server operator.

[WolfganP]

My view is that any server not under the control of anyone participating is intended for casual sessions and in case of any participant's issue some lite troubleshooting, as you're missing the server side control/analysis features.
Adding per participant latency metrics on the client won't help much in case of any serious performance issue, and may be too much info for most of non tech users.

[gene96817]

I agree that the server sees some important parameters. However, it would be great for those parameters to be available without having administrative (OS) access to the server. I have reservations that any serious use of Jamulus requires that ensemble to operate their own server. This biases the community culture to one server per (serious) ensemble. This seriously contributes to creating a Jamulus ghost town.

[ghost]

I think showing someone else' latency will utimately not deliver what was hoped for. I would give credit to those that can keep the song together, don't split the difference with latency. Jamulus will give you practice that will make you a better musician unless you give up, so sing or play through the latency or go home.
My prediction is that anyone that wants this feature will not be using it so fast that they will have forgotten about it by the time the developer asks them how they like it.

[hoffie]

Jamulus will give you practice that will make you a better musician unless you give up, so sing or play through the latency

I agree. After practice it is possible to make music even with high latency (we have people with 80-100ms latency in our ensemble).

I still see value in having the latency information readily available, especially for larger ensembles. This helps to identify possibly slow people and reminding them to listen to their signal from the server, for example. This is possibly by trial and error as well (e.g. Mute people one by one), but much more cumbersome.

[gilgongo]

@FransFrijns When you say "to help troubleshooting problems during sessions", can you elaborate on what action you would (or would not?) take if you could see for example one member had a ping time of 10ms and overall latency of 50ms, while another had ping of 5m and 25ms?

I ask because there is a family of feature requests like this that might be classed as "telemetry" requests: showing more data about the states of things. Given the relative difficultly of providing that data and choosing how to display it, it's good to know a bit more about the reasons why it's needed.

[FransFrijns]

Hello Gilgongo, Hoffie and all other contributors...

During rehearsal / band lessons, the ensemble constantly gets stuck. Often they stop playing and discussions arise. Requesting everyone's latancy and ping times is then a hassle. In addition, the latency fluctuates. By the time you have requested the latency time of each musician, these times are completely different.

It is indeed possible for experienced musicians to play with the delay, but with less experienced musicians that is a completely different story. If you are not yet very experienced in listening to the others and responding to what you hear, playing in time is much more complex. For example, in one of the bands that I coach the drummer says that he thinks he has to play a complete beat earlier the rest while his latancy is about 70 ms, in my opinion that is not so big that this explains a whole beat difference.

A next member in this band is a blind bass player. This is an extra problem because although he still can participate with the help of his elderly father, obtaininging technical information and adjustinging settings is very complex from a distance. Not knowing what is going on at the members computers makes me feel also a kind of blind.

Although the knowledge about each latency times does not provide a direct solution, it could certainly help to identify which participant has the biggest problems. That would also give a good indication where to start trouble shooting in the first instance.

Thanks for your input!

[gene96817]

425 or 500 ms, close enough for now.
I believe that the delay can be larger than the buffer size. I have written about this in another thread. There is a possible mechanism that the time offset of the stream can accumulate more than the buffer size. The buffer size is for absorbing jitter. If a underrun is followed by a related overrun event that does not flush the buffer, then the time offset at the moment of the overrun is preserved. These events can be stacked and the time offset (the cumulative delay) will grow. In any case, I don't think a musician can compensate for a 200+ ms delay and sing/play in sync.

[dcorson-ticino-com]

I don't think a musician can compensate for a 200+ ms delay and sing/play in sync.

That's for sure.
But you say this starts from smaller values and works up. From what values does it start?
My experience is that anything more than 50 or 60ms is unplayable.
I have not noticed that people that listen in with higher delays cause problems, as long as they don't try to join in and play.
For such extreme cases as you describe maybe going through the books for the jitter buffer management would be helpful.
But for extreme cases like you at the edge of the world I doubt it will make a real big difference.

[gene96817]

extreme cases

Well, maybe you can call these extreme cases because it doesn't happen where you live. I am at the edge of the universe (UTC-10), and jitter is worst than what I would consider acceptable before I moved out here.

For such extreme cases as you describe maybe going through the books for the jitter buffer management would be helpful.

I am familiar with buffer management. I consider what I see as a perverse combination of jitter and buffer management for audio (real-time) streams. I am looking for data to support my conjecture that (1) Jamulus buffer management tries too hard to never lose a buffer and (2) judicious use of buffer flushing would prevent the creeping cumulative delay. Books on buffer management would never get into this kind of challenging scenario.

[dcorson-ticino-com]

I am not an academic, by going through the books I meant taking a good hard look at what Jamulus really does in its buffer management. I am putting that on my to-do list for the coming weeks.

[gene96817]

@dcorson-ticino-com Thank you. Since I can't read Jamulus code, I can't research what is under the covers. I would be glad to discuss what you find.