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.