Show input signal level before connecting to server

[kwindrem]

Currently, the Input meters do not show a signal anything until you are connected to the server. In order to verify connectivity and set levels, showing the level even if not connected to the server would be valuable.

Showing the client's mixer channel and routing the client's input audio to that channel would also allow testing the Jamulus output path.

Cosmetically, shouldn't the Reverb controls be associated with the client's input? That is, doesn't this add reverb to the signal sent to the server? It looks like it's associated with the client mixer.

[ann0see]

Yeah. This would be great! It could go with my request of implementing a sound check. #534

I think the mixing board should then show a message saying

"Connect to a server to start jamming!"

And two buttons: [Connect] [Open Settings] The first opens the server dialog while the second opens settings to chose the correct sound card, etc.

This message would clarify that you are not connected to a server yet and maybe need to setup your audio gear.

If the levels move but you don't hear anything, it might be a bit confusing for current users.

[gilgongo]

It could go with my request of implementing a sound check.

Yes - because Jamulus presents itself as a mixing desk, if you interpret what you see in the UI in terms of what you understand from a real-world desk, then there could be problems. A mixing desk would normally show "input" levels working even if speakers were not connected (if by "speakers" we mean the server). So perhaps being clearer about the status of the sound path would be helpful. There was as lot of confusion around "mute myself" too, for example, which I suspect may partially have arisen from mixing-desk misconceptions.

I did once sketch up a re-arrangement of the UI trying to be clearer about the sound path. This showed a sort of "chain of connection" across the top of the screen, so client input > sound to server > sound from server (with status and simple strength levels for each). If I can find it I'll look at it again, but I don't know if there's much appetite for large UI changes really.

[ann0see]

I don't think the UI should be greatly changed. What could be done of course would be a different background for the mixer board (where all the sliders are) and the part on the left. This would allow a visual separation.

[ann0see]

I'm currently looking through the code how to enable this. It seems to be a bit complicated probably because the Client class only starts to process audio if the connect button is pressed. I'm not sure about that, but I think this is the case?

Can we access the sound card before that? I think so. It would also enable us to throw better error messages if the sound card can not be accessed. I think in general the Jamulus window should look different if there's no connection (we could hide the delay and buffer buttons and move the connect button to a even more prominent position (e.g. to the mixer board which in my opinion is wasted space if there's no connection to a server). This would simplify the UI even more.)

[corrados]

Currently, the Input meters do not show a signal anything until you are connected to the server. In order to verify connectivity and set levels, showing the level even if not connected to the server would be valuable.

We have a lot of empty Jamulus servers available. If I want to adjust my input signal level, I simply connect to one of the empty servers. So I see no need to change anything in the Jamulus client.

[gilgongo]

a different background for the mixer board (where all the sliders are) and the part on the left. This would allow a visual separation.

Although unless the user understands what the relationship is between those parts, I doubt that would have much effect.

So I see no need to change anything in the Jamulus client.

Perhaps not, but I think @ann0see is looking for ways of making Jamulus easier to understand and therefore troubleshoot. As I understand it, the OP wouldn't think to connect to an empty server to adjust levels, since they would assume (logically, if in error) that no sound would get to the server.

[ann0see]

I totally understand corrados in the means of being able to check sound levels by connecting to a server. But that only works if the internet connection is ok or if someone is running a server on localhost (newbies will not know that). As far as I see this request requires quite some rewriting?

I agree on gilgongos answer: it would improve user experience.

[corrados]

When I set my input levels, I do not only want to see the meters but hear the signal. Even if the meter shows that the level is ok, you could be overloaded on the analog side. Also, your signal goes through 2 OPUS encodings which could also modify your own signal. So I see a connection to an empty server as a must to set the input levels/EQ/whatever correctly.

[ann0see]

What could be done to allow this would be a button/entry in the menu bar to start a (headless) private server on localhost with automatically connecting to it.

If jamulus is not connected to any server the mixing desk, level meters and leds should look disabled/hidden and the connect button even more prominent (like zoom does it). This would allow a even simpler gui.

[gilgongo]

start a (headless) private server on localhost with automatically connecting to it.

A function to "test your setup" in this way might be very valuable. This is because I think most people would naturally not connect to a server unless they could hear their own signal before they did so. But if they can hear their signal before they connect, that will sabotage their experience of Jamulus.

In fact, to what extent is this scenario crippling many people's use of Jamulus so that they conclude it's not any good?

[drummer1154]

I stumbled upon this Issue by chance and I 100% support the first and third paragraph of the request in the initial comment. I also demanded this feature in https://github.com/jamulussoftware/jamuluswebsite/issues/174. The reason is that it took us a lot of time to get the environment up and running (and still I have the issue that my Omega says it is not initialized correctly).

@corrados Why is it so hard to understand that when beginning using Jamulus I want to get my personal instrument/audio interface/computer environment up and running correctly prior to adding complexity (as setting up a local private Jamulus server and connect to it - of course on a separate computer within the LAN so as to not add additional CPU load on the computer to which my instrument is connected). And of course I agree that this is an inevitable step to take prior to connecting to any active session.

My change request for the mute myself feature goes into exactly the same direction - prior to "breaking into" a session I want to be sure that my audio is OK - and for this test of course a remote server is required.

[gilgongo]

If I were to speak for @corrados and his perfectly effective initial answer to the question: can you explain why connecting to an empty public server doesn't solve your problem?

I'm not saying you're wrong, I'm just interested in what your reasoning is.

[drummer1154]

I already did: Because it adds complexity, i.e. it broadens the field for failures. Getting my local computer environment up and running by itself without the need to go over any external network excludes these sources which are completely out of my control.

[gene96817]

I support the idea that we need a standard start-up procedure for new users. Helping to onboard new users can consume a large amount of time and getting a new user introduced to a group disrupts the groups jamming time. Ideally, a standard process of: 1- check out the chat function (client is mostly working) -- use the chat window to guide the new user through the pre-jamming setup 2- check out the sound output (to headphones) from the client 3- check out the microphone input ----- at this point when the user connects to the server, we don't have to revisit the client driver configuration or hardware connections ---- if new user can't get past first three steps they can ask for help without disrupting a jamming session. too many sessions are just helping a new user get configured. 4- first server connection (no jamming partners needed) -- a guided tour to the settings settings 5- finally, first jamming session. -- (I would be really happy to start here to help people).

can we add a start-up function (code) for steps 1 - 3? Keep it simple, it is just self-check so that we know these steps are not the reason that the first jamming session has problems.

[gilgongo]

@gene96817

use the chat window to drive the pre-jamming setup

What do you mean by that?

BTW I think the idea of a "setup wizard" is a good one if it's possible to do. This has been discussed before in fact (can't find the ticket but I think @ann0see raised it), but without resolution so far.

I would imagine a setup journey would have to be very platform specific. So for example in your points 2 and 3. if you could not hear yourself then maybe your ASIO setup is wrong (and I think in about 90% of cases it would be). Guiding the user through the ASIO screens is obviously different from if they're on Linux using Jack, or Mac. And in all cases we have to leave the user to make the right decision about which audio device they choose for what I/O (unless we can narrow it down for them by detecting the one(s) that have suitable sample rates and buffer sizes?)

[gilgongo]

Hi all - I think this is essentially now a duplicate of https://github.com/jamulussoftware/jamulus/issues/991 so in an effort to keep the Issues tidy I'll close this now if that's OK.