Suggested enhancements to "settings" panel of the client

[marktheharp]

Hi! Having used Jamulus for a while, I notice the support notes / hover notes don't give a useful guide to some of the functions on the Settings panel on the Jamulus client, and in one case (number 2 below) actually imply the opposite of what's happening. I propose the following might be useful especially to newer users:

1 - On the "Jitter" faders it's taken me a while to work out that "Local" refers to audio incoming to your machine and "server" refers to outgoing buffer settings. Assuming that's right, I suggest these are changed to "Incoming" and "Outgoing". That makes more sense of the relationship between the client (which is what calls up the settings panel) and server.

The small green/red indicator should really be underneath the left-hand (incoming) fader. It might be useful to have a similar indicator underneath the right-hand one, showing the quality of what is being received at the server - that would be useful because unlike the “incoming” stream, you cannot hear when there are issues unless you are monitoring your own output.

2 - On "Misc" the wording is actually opposite to the meaning! Mono in / Stereo out doesn't do what you might think it does. When this is selected, the the input to the client is stereo (or at least pannable) and the output of the client to the server is actually mono, not stereo. It therefore makes more sense for that choice to be labelled "Stereo in / Mono out"! I discovered this after wondering why my recordings on the server were in mono despite thinking Stereo Out meant what it said!

Finally, and just out of interest, what do the numbers actually mean on the buffer sliders? 1-20...what?

[chrisrimple]

For Misc > Audio Channels, I recommend "Mono out / Stereo in", leading with what the client is sending first.

[marktheharp]

For Misc > Audio Channels, I recommend "Mono out / Stereo in", leading with what the client is sending first.

I agree, but unfortunately it’s then the opposite way round to how the jitter “faders” are arranged (they are input to client / output from client), which is why I suggested the other wording. It keeps the thing consistent, especially as “Jitter” and “Misc” are adjacent to each other on the settings panel.

[pljones]

I'm not 100% on the jitter sliders but I think:

• The left hand jitter slider refers to the buffer for data output by the Jamulus client to the server. Maybe just changing the label to "Client" would do?
• The right hand jitter slider refers to the buffer being used to return data to the Jamulus client from the server.

For the Audio Channels, again, my understanding is

• "Mono" means a single channel of input into to the Jamulus client (see "Input Channel Mapping") and a single channel of output from the Jamulus client (see "Output Channel Mapping")
• "Mono In/Stereo Out" means a single channel of input into to the Jamulus client (see "Input Channel Mapping") and a a pair of channels of output from the Jamulus client (see "Output Channel Mapping")
• "Stereo" means a pair of channels of input into to the Jamulus client (see "Input Channel Mapping") and a pair of channels of output from the Jamulus client (see "Output Channel Mapping")

However, on that I'm not 100% certain as it doesn't affect the mappings themselves. If I'm right, it might be helpful if it did.

(The server takes a mono input and uses it in twice to get a stereo mix for a stereo out client and it mixes to mono out any stereo pair received for a mono out client. But the "mono in", "stereo in", "mono out", "stereo out" still refer to the client, really.)

[marktheharp]

Hi thank you for your comments – but in fact this is a really good illustration of what the problem is that I was trying to suggest a solution to. Actually both of these below are wrong. And they are exact exactly opposite to what actually happens.

Hence I was suggesting better labelling.

I'm not 100% on the jitter sliders but I think:

• The left hand jitter slider refers to the buffer for data output by the Jamulus client to the server. Maybe just changing the label to "Client" would do?
• The right hand jitter slider refers to the buffer being used to return data to the Jamulus client from the server.
• "Mono In/Stereo Out" means a single channel of input into to the Jamulus client (see "Input Channel Mapping") and a a pair of channels of output from the Jamulus client

[pljones]

It seems backwards, to me, that the left hand jitter slider would refer to data being buffered at the server not yet received, with the right hand client referring to data at the client not yet sent.

If it is, then I think it's not an error in labelling (i.e. left should be local, right should be server) but in what value they're displaying.

@corrados can you confirm?

[corrados]

If you transmit audio UDP packets through a network, you need to have a jitter buffer on the receiver side. So, the left slider labelled "Local" refers to the jitter buffer at the client which receives the audio UDP packets sent by the server. The right slider labelled "Server" refers to the jitter buffer at the server which receives the audio UDP packets sent by the client.

Maybe just changing the label to "Client" would do?

I could change the label "Local" to "Client" if that helps.

[marktheharp]

Got it. I know the server software and the client software are essentially available in the same package, but the "server and client" labelling to me still seems not to really look at things from the perspective of someone in a session using the client software - as that's where the panel appears (not on the server software).

Hence for me personally "incoming" or "receive" are better than Client (which is not a term many people know anyway) and "outgoing" or "send" is a better name than "server" (even though technically it's "at" the server end of the process), for similar reasons. You could try a facebook poll I guess to see what other people think. Honestly, I couldn't work out what the "server" one did until I experimented with someone else joining me on a server.

I do think this would be great added to the F1 / help info as that would help people's understanding of the two.

And having the single light underneath didn't help my trying to understand what the two controls did. So if there's any way we can add an indicator for dropouts which are being received at the server that would be really helpful, as anyone joining a session won't hear those dropouts, only the incoming ones.

[drummer1154]

Please note that all jitter buffers are "incoming" - regardless whether "server" or "client" is referred to. Maybe it would be a good idea to have a look at "Figure 2: Simplified Jamulus block diagram" in Volker's document llcon.sourceforge.net/PerformingBandRehearsalsontheInternetWithJamulus.pdf. So for me the current labeling "Local" and "Server" is clearly understandable as well as the left/right assignment. If you set up a local private server (on the client computer or on a separate one) then you can see the effect of adjusting the "Server" slider immediately. Cheers Helmuth

[pljones]

OK, I'd got my "Audio" and "Network" ins wrong for the buffering...

"Local" refers to the jitter buffer at the client which receives the audio UDP packets sent by the server.

"Server" refers to the jitter buffer at the server which receives the audio UDP packets sent by the client.

Thus the flow would be:

Audio In -> Network -> "Server" jitter buffer for this client -> Mixer -> Network -> "Local" jitter buffer for the mix -> Audio Out

Right? That's why having the "Local" on the left and the "Server" on the right feels wrong... it's against the flow...

[corrados]

Audio In -> Network -> "Server" jitter buffer for this client -> Mixer -> Network -> "Local" jitter buffer for the mix -> Audio Out

That's correct. BTW, you write "Audio In" and "Audio Out". That is the reference for "Mono In/Stereo Out". It refers to the audio coming in and out of the audio device.

That's why having the "Local" on the left and the "Server" on the right feels wrong... it's against the flow...

Why must the order of the sliders reflect the flow? There is a label above each sliders which clearly states to what it belongs.

[marktheharp]

Personally I think the order of the sliders is absolutely correct. It’s just the labelling is not very user-friendly to people who are used to signal flow in conventional mixing desks – which is after all, what the client is trying to emulate. If you think of the client as a mixer – which is what it looks like, and is in effect what it is - the local slider represents the inputs to your mixer, and the server slider represents the output of your mixer.

I do understand it now myself – having played with it – but the whole client/server labelling makes no sense to people new to it.

If no label change is proposed then it would definitely be well worth having the help dialogue different for each of the two sliders. Honestly, unless I’ve missed it, there is nowhere where the different functions of these two sliders is explained.

Can I just add, I am not particularly familiar with server/client/networking stuff. I worked in broadcast so this is my background. But one of my bandmates currently works for IT in the military, and he didn’t understand the labelling either. So I don’t think it’s us being stupid.

[drummer1154]

Preface: Needless to say that nobody thinks or says that anyone else is stupid.

Maybe it is worthwhile to explain server and client architecture a bit more global as it is not necessarily bound to networking but it is used in a wide range of technologies and can be implemented in hardware, in software, or a mix of both. Simply spoken a "server" is a single computational unit which provides (one or more) "services" to (one or more) "clients" (which could also be called "customers"). A server needs to "open a door" for any client to request its service. This means the client needs to take action first. Then the server decides whether or not it accepts the client and provides the requested service back to the then "registered" client.

In Jamulus, the "clients" sample their individual audio streams, send them to the "server" in order to be mixed and be sent back to all clients which are connected to the server. So the provided "service" is "mixing audio streams". Activating the "Connect" button sends a request to the selected server, and if the server accepts, the server mixes the audio from the requesting client to the audio of already registered (connected) clients (if any) and sends the mix back to all registered clients.

The "jitter buffers" are completely unrelated to client/server architecture. They are just a required technical implementation to compensate for changes in the delay time data packages encounter when sent via the internet. There is one buffer on the receiving (incoming) side of each client/server connection, therefore we see two sliders (and maybe the label of the section should better be plural "Jitter Buffers"). The slider settings reflect the number of buffer entries (or "slots") which are provided on both sides. The "Auto" fuction adjusts these settings automatically and should be taken as a starting point for manual tweaking. As far as I can see the settings are not at all related to the audio flow, but only to the computational capabilities (and the network infrastructure) of the involved computers, but of course suboptimal settings will lead to excessive audible delay or even to audio dropouts or cracks, as will settings for e.g. the ASIO drivers. Therefore it is only important to know which buffer is influenced by which slider so as to be able to decide to look for a better server in case the current server requires too many buffer slots.

One implementation detail should be clarified by Volker: In case the color of the green/red dot placed in the middle below the two sliders is indeed controlled only by client computation, I would suggest to remove the dot and change the color of the client slider instead. And please correct me should I have explained something incorrectly.

[pljones]

If we think of the jitter buffers relating to the "mixing desk flow", then:

• the "server" buffer is before the signal hits the desk but only for this client (not for any other client)
• the "local" buffer is after the desk, as the signal returns from the server to this client

Why should the order follow the flow? To make it easier for people to understand? This issue shows it's not easy.

[marktheharp]

Absolutely agree it’s not easy to wrap one’s head around! I like Peter’s use in his post of “return” and that’s another useful distinction / label. But otherwise I think of the server buffer as after the desk (else I would hear its effect on any of the channel faders, and the only one it affects is mine, if I have myself faded up) and the local as before the desk (because it effects everything I hear and it helps me to therefore think of it is before the signals get to my desk).

Where I’m coming from, I guess I don’t really care what the server is doing as that is largely out of my control. I only care about understanding how the buffers affect what I hear, and how the buffers affect what other people hear from me. Hence for me it helps thinking of the local as before the desk, and the server as afterwards, but I appreciate Peter’s viewpoint and I think I can almost agree with it if I think hard enough

[marktheharp]

And thank you drummer1154 For that explanation of client/server. That really helps.

As I can only hear the effect of the server buffers when I am listening to my own input being returned, I would value a similar indicator underneath the server slider, to indicate if packets are being skipped. In a way that’s almost more important, because you cannot normally hear yourself – or choose not to – but it is important for everyone else to be able to hear you without skipping, and you may not be aware of how you are being heard without some sort of indication.

So ideally I would like to keep the dot underneath the local, but definitely add one under the server slider. If that’s even possible. But I’m assuming the same code that sets the buffers to auto, must therefore have some sort of awareness of how many packets are being skipped (if that is the right term) by both sets of buffers, and therefore it could control an indicator.

I also found it incredibly useful that you were comparing servers – basically if I understand it correctly, saying that some servers may require more buffer slots than others, which could be down to the equipment running a particular server, as well as the route your signal has taken to get there. To be honest I hadn’t thought of the role of the servers themselves and how they might differ between each other.

Thank you for helping my understanding of this. I am even coming round to thinking of local and server as being useful labels but it still slightly grates – however accurate their labels – when I’m faced with a thing that looks like a mixing desk!

[drummer1154]

it is important for everyone else to be able to hear you without skipping, and you may not be aware of how you are being heard without some sort of indication

If I did not completely misunderstand the principle, all clients receive the same mix. Edit: This statement is wrong - every client receives a separate mix based on the "channel strip" settings in the main window. /Edit Therefore if you can hear yourself undistorted, you can be sure that everyone else also does. Maybe this is not clearly enough visible in the block diagram I mentioned earlier, because it only shows the input of "other client", but not the output to this "other client" which I believe is the result of "mix all audio" - think of this as a common rail to all clients.

I am, however, not certain at which point in the signal path the local client's faders and mute buttons for the other clients cut in - I will check this out when we rehearse tonight. Edit: "Techy" audio signal diagram see https://github.com/corrados/jamulus/issues/64#issuecomment-633309575. Important detail: If you "mute yourself", you can still hear yourself but the audio signal bypasses the server - so in this mode you cannot test connection related problems (jitter, delay etc). /Edit

One additional thing as you say:

when I’m faced with a thing that looks like a mixing desk

The mixing desk view is indeed related to the audio processing, but the jitter buffer "faders" are not - they merely influence the behavior in time of the (audio) data packages, without any effect to their contents (with respect to volume etc).

2020-12-09 Edit: Correct mistake caused by incomplete block diagram, added link to current audio signal diagram.

[marktheharp]

I get that about the jitter “faders” – so on reflection it’s good that it is a separate little window.

Regarding the other point, about hearing oneself – yes, you are right, you can do it that way, but obviously if you are joining a session late, you don’t really want to interrupt people by asking them if you sound okay, or even by fading yourself up and experimenting. Because in doing that you are disrupting the session. Besides which, any break up in the sounds could be because of your local buffer settings as well as your server buffer settings. Hence it would be great to have a separate visual indicator then you could target the appropriate slider straightaway. I guess you could mute everyone else and just hear yourself, but again you will be audible to everyone else on their clients.

Still, thank you, I hugely appreciate this discussion as it’s helping my understanding of the whole thing. I haven’t grown up with Jamulus, I’ve joined a relatively recently, within the last couple of months.

[corrados]

I would value a similar indicator underneath the server slider, to indicate if packets are being skipped

Since the jitter buffer is located at the server, the client does not have the information. The server would have to ship that information via the protocol mechanism.

because you cannot normally hear yourself – or choose not to – but it is important for everyone else to be able to hear you

As written many many times, it is important that you listen to your signal coming back from the server and not your direct sound. Otherwise you slow down the songs or you make the other players do not enjoy jamming with you.

In case the color of the green/red dot placed in the middle below the two sliders is indeed controlled only by client computation

Yes, the LED shows the status of the jitter buffer at the client only. It is the same LED as you have on the main window (the "Buffer" LED). Since the two LEDs in the settings dialog do exactly show the same state as the LEDs on the main window, I was considering the remove the LEDs in the settings dialog so that we just have LEDs on the main window. Then there is no issue with "to which slider the LED belongs to".

[pljones]

But otherwise I think of the server buffer as after the desk (else I would hear its effect on any of the channel faders, and the only one it affects is mine, if I have myself faded up)

No, it's before the desk if it's on the buffer of the data you send to the server, because the server is the desk! It can't be after the desk.

and the local as before the desk (because it effects everything I hear and it helps me to therefore think of it is before the signals get to my desk).

Similarly. The client must be after the desk, as it only has the mix from the server.

[drummer1154]

@corrados : I do not think that removing the indicator from the settings dialog is a good idea because if you try to optimize your settings you will have the settings dialog in focus and not the main window. What about my suggestion to change the slider color?

[corrados]

I do not think that removing the indicator from the settings dialog is a good idea because if you try to optimize your settings you will have the settings dialog in focus and not the main window

I usually have the settings window and the main window side-by-side so I can see all LEDs. Removing the LEDs has advantages:

• The code in the settings dialog is cleaner.
• Since we now have 4 LEDs, some users might think that they show 4 different states but this is not the case. Two of them are just a copy of the other and therefore redundant.
• Since the buffer LED is below both jitter buffer faders, this is confusing to what it belongs (only for client actually).
• For optimizing the jitter buffer settings you need to listen to your audio signal anyway. The LED is just an additional indicator but the more important indicator is how your signal actually sounds. Since we have packet loss concealment in the OPUS codec, sometimes you get a red LED but you hear no audio drop out at all.

[corrados]

I just created a separate Issue for removing the LED indicators: https://github.com/corrados/jamulus/issues/762

[marktheharp]

@corrados : I do not think that removing the indicator from the settings dialog is a good idea because if you try to optimize your settings you will have the settings dialog in focus and not the main window. What about my suggestion to change the slider color?

Not sure about the slider colour thing, but definitely I agree with you that removing the indicators from the settings dialog is not such a good idea for exactly the reasons you put.

[corrados]

but definitely I agree with you that removing the indicators from the settings dialog is not such a good idea for exactly the reasons you put.

Well, my argument is the following (as given above):

For optimizing the jitter buffer settings you need to listen to your audio signal anyway. The LED is just an additional indicator but the more important indicator is how your signal actually sounds.

The LED indicator might imply that this is the only metric but this is not the case. The metric should always be the audio you hear, not a LED.

[drummer1154]

For me the current situation to have 2 Issues containing discussion related to the two "LEDs" is not very good. From my PoV #762 is a subset of this Issue (#747) and currently I need to enter the same arguments here and there. The better way would have been to finish the discussion here and create the new Issue only when the proposed change is accepted.

... you need to listen to your audio signal anyway ...

There is absolutely no doubt about this fact. But please see https://github.com/corrados/jamulus/issues/762#issuecomment-739504253.

[pcar75]

@corrados

Interesting information thread, though I'm confused by your statements :

If you transmit audio UDP packets through a network, you need to have a jitter buffer on the receiver side. So, the left slider labelled "Local" refers to the jitter buffer at the client which receives the audio UDP packets sent by the server. The right slider labelled "Server" refers to the jitter buffer at the server which receives the audio UDP packets sent by the client.

Here is what I understood from the first part (from various diagram, not actual session) . . Since the jitter buffer is located at the server, the client does not have the information. The server would have to ship that information via the protocol mechanism.

What wrong with my understanding ?

• Doesn't the server tells it's jitter buffer to the client using it ?
• The Client>Settings>Jitter Buffer > Local and Server values represent the number of Client Windows>Buffer Delays selected size (in ms or samples). Right ?

Thanks for any clarification.

[pljones]

The question was about the LED, though? The LED indicates buffer fails. That information isn't shipped, only the buffer size. So for the client to know about buffer fails, to illuminate a buffer fail LED, a new UDP protocol message would need to be sent holding that information.

If I've understood it...

[pcar75]

Well, my questions are still remain ...

Further questions on this

• "(...) the server tells it's jitter buffer to the client using it (...)" would be true for 'auto' enabled as the server is better placed to judge the number of jitter buffers it needs to serve that client. However, since disabling 'auto' allows both client and server jitter to be set by the client, then the client does communicate these values to the server. Right ?
• Or is it that there is some constant nb-of-buffers 'negotiation' between server and client when 'auto' is enabled ?
• for the LEDs, I suppose that a client side module does the calculation from hard/soft-coded ranges to apply the proper colors for jitter buffer and overall delay ?

Also for owner/moderators of this discussion facility, please advise me if I should place (or recreate) this part of the thread in another discussion . If so which one and in which forums (Sourceforge or this Github , though the former seems to be more aimed at users and the latter at developpers) ? *My 'social media' use and netiquette are mostly limited and 'Mon (canadien-) français est tellement meilleur' (my french (-canadian) is so much better ;-).

[gilgongo]

@pcar75 We try to keep Github tickets to bugs and feature requests, while "support" issues and questions are on the Sourceforge forums GitHub Discussions.

[gilgongo]

Hi all - since there's some debate about what exactly we'd like to do for this issue, I'll migrate it to a discussion. Once we have one or more actionable specs for Issues we can then raise them for the backlog for people to work on.