Ideas for more meaningful 'Jitter LED' in Client Dialog

[passing]

Right now the 'Jitter' LED has just 2 states:

• Red for any number of errors within a 300ms interval:
  • Client Jitter Buffer failure https://github.com/jamulussoftware/jamulus/blob/master/src/client.cpp#L1145
  • "audio" / "generic" errors reading audio packets https://github.com/jamulussoftware/jamulus/blob/master/src/socket.cpp#L281-L282
• Green for none of these

I tried to make this more meaningful and modified the code to actually count the different errors (counters reset in a defined interval just like the status) and show the counted values next to the LED (which then can also go yellow for a low number of errors):

I think it at least looks nice and may be helpful in some cases, still for many users this may not give any benefit.
So I would like to get some feedback if that (or part of that, or something similar) is desirable, before I put more effort into nice and shiny code ;)

[gene96817]

Sorry, I am a dunce reading the code from the link you provided.
What are the conditions for buffer failure? It seems that buffer underrun or overrun counts as failures.
What is the meaning for Jitter =x/y?
Thanks....

[ghost]

I think the LEDs are good enough. Less is better, more is burdensome.

[passing]

@gene96817

What is the meaning for Jitter =x/y?

I assume that

• x is the number of buffer underruns in the Client Jitter Buffer
• y is the number of buffer overruns in the Client Jitter Buffer

but I am also not too experienced in the Jamulus codebase, so this may not be correct

[gilgongo]

When you say "may be helpful in some cases" what would somebody do if (for example) the errors were 5/0 as opposed to 0/361? If counting the errors get you closer to a reliable action to take in order to fix the errors, then I'd be more interested in showing a call to action about that ("Make your buffers bigger"?)

[passing]

That's exactly what I hope to clarify here as I just don't know.

Having looked a bit more at the code now, I think there are actually just 2 relevant cases that cause a red LED:

1. CChannel::GetData returns GS_BUFFER_UNDERRUN
   which obviously seems to be a buffer underrun
2. CChannel::PutAudioData returns PS_AUDIO_ERR
   which I assume is a buffer overrun (?)

And I now just counted and displayed these separately.
I'm especially unsure about the 2nd case: That counter goes quite high on some servers, independent of the buffer settings

[gene96817]

With the explanations, it seems that x/y should be errors of any kind, with x = inbound errors and y = outbound errors.
However, outbound errors (specifically, buffer overrun) are of limited utility. This would be a delay in the Jamulus internal data flow. If the path has multiple hops, the x/y is not actionable since we still don't know what hop contributes to the error.

[passing]

the display could just be reduced to a single number which would show the buffer underrun count as a positive number and the buffer overrun as a negative number. then the tooltip could explain something like:

• small positive number are usually acceptable, for a bigger number the buffer should be increased when the audio quality is getting bad
• negative numbers for a longer time indicate an issue in the client or server

[ghost]

Jamulus is supposed to adhere to the KISS principle. Numbers beside LEDs add to confusion and code bloat and cpu load and battery draining and global warming. The LEDs are sufficiently sufficient.

[passing]

got your opinion already after the first comment! I still want to get some more.
If this turns out to really not provide any value, I'm totally fine with discarding it.

[passing]

I agree to the feedback that - if at all - the additional information should be kept at a minimum. So my proposal would be just a single number counting the underruns and showing overruns as a negative number when there are no underruns (usually doesn't happen):

Also noticed that a common problem for buffer underruns is using wifi (which of course you shoudn't), so I'd include that in the tooltip

draft for information to be added to the tooltip:

• small numbers of jitter buffer errors are usually acceptable
• when audio quality is bad while the counter shows a bigger value (to be defined)
  • ensure a stable network connection: use a network cable instead of wifi
  • otherwise try increasing the local jitter buffer
• negative numbers for a longer time indicate an issue in the client or server

I have committed my modifications on a branch here: https://github.com/passing/jamulus/tree/jitter_failure_counter
It would be nice if you could try it out yourselves before judging on it. It makes much more sense to see this in action instead of on a screenshot. ( @jamulussoftware/maindevelopers , it would be nice if one of you could try it as well )

[gene96817]

What causes the buffer underrun count to increment? Does it increment during longer periods of undnerrun?
A buffer underrun effectively inserts a time offset (delay) to the audio stream. This offset is cumulative. The only way to eliminate this offset is to flush the late packets. Does the code have the ability to flush late (or very late) packets?
Since the code can detect out of order packets, the packets are numbered. This makes it possible to know how many packets need to be flushed.

[gilgongo]

Jamulus is I hope mainly about playing music, not signal analysis. So for something to be on the main screen as opposed to another screen, there needs to be some clear rationale for it in terms of playing music. For example, the sliders are there for when you can't hear someone well enough, or they are too loud. So you adjust them. The level meters are there so that you can tell which channels are active and by how much so that you can decide to mute, pan, turn them down, etc.

Is there any "musical action" you can take on the info displayed by the jitter/ping status? Indeed, removing it all has been discussed in the past by Volker and others on just these grounds. So as @ann0see says - is about the analyser console because playing and analysing your sound are separate things.

In fact, @passing your answer to my question above seems to confirm this: #1815 (reply in thread) In general, information presented by UIs need to have clearly actionable reasons to be there.

[passing]

What causes the buffer underrun count to increment?

@gene96817 the only way I found by accident to get the buffer overrun up (i guess you wanted to know about that?!) was a lower frames/second setting in jackctl than the hardware could handle (resulting in no sound being output).

[gene96817]

@gilgongo I am interested in your opinion of my observation. Think of it as an extension of correcting out-of-order packets. Nothing needs to be seen at the UI. This affects sound quality under jitter conditions.

[gene96817]

I found by accident to get the buffer overrun up (i guess you wanted to know about that?!) was a lower frames/second setting in jackctl than the hardware could handle (resulting in no sound being output).

I was asking about underrun. As to overrun, yes if you have something in the data path that has a low frames/second, you will have an overrun condition at the bottleneck that causes packets to be dropped. With enough dropped packets, there will be no sound output.

[passing]

for something to be on the main screen as opposed to another screen, there needs to be some clear rationale for it in terms of playing music

@gilgongo well my intention is not to have this on the main screen. Just the small section dedicated to showing technical metrics is already there:

In that section, the LEDs alone just tell: green=good, yellow=not so good, red=bad. And there's also numeric values for Delay and Ping. So I just thought: there's a huge gap next to "Jitter", why not also put the number there that quantifies that Jitter LED. 😄

Anyway, part of my change is to have yellow color on the Jitter LED as well, as right now a single underrun makes it red already. And I think red should only be shown if something is really bad.

In general, information presented by UIs need to have clearly actionable reasons to be there.

I think that still makes sense:

• For a small number of buffer failures (yellow): no action is required
• For a larger number of buffer failures (red):
  • same hints as now (jitter buffer, sound card buffer, internet rate, cpu) and one more: replace wifi with wired connection

[gilgongo]

OK, so that's the sort of "indication to action" thing I'm talking about: if X then do Y. But you don't need Ping and Delay and Jitter LED, and have numbers next to them to achieve that - indeed you could just automate it. We show a "muted" icon today if a channel cannot hear you. Show a "disrupted" icon next to the channel that's disrupting if that's all that matters at the end of the day. Why all the UI invasion?

[passing]

indeed you could just automate it.

I agree that would be the ultimate goal, but hard to achieve

I don't agree that providing more information on the main UI is a problem in general. While using Jamulus, I just play music and don't look at the UI almost all the time. But when I want to adjust something or see if there are issues, I prefer having everything at hand quickly (and don't mind seeing more information than I need)
But that's just my personal opinion and I'm fine with the different feedback I got - so will stop this initiative here.

[gilgongo]

In so far as channel mute status is being sent to the server today, I assume a "disrupted" indicator would not be too hard (although I'd guess it would need a protocol change). Given that it seems to solve the problem behind the problem, as it were, could you not shift the initiative in that direction? You have articulated a problem after all. I'm simply objecting to the execution of proposed solution.

[passing]

if I understand you right, you are talking about distributing connection-quality related information via the server to the clients? Then I guess that specific requirement should be part of #961

But that's probably way outside of my still quite small comfort zone in regards to C++

[gilgongo]

It depends what you mean by "connection quality". If it's stuff like jitter buffer numbers and ping stats, then forget that for the reasons I've stated (they're basically useless). But if it's a simple "something is probably perturbing the signal" flag the yes, because that's actionable and seems useful in the way you have described.