Local-Loopback mode for audio driver test

[nefarius2001]

When setting up Jamulus for someone new, choosing the right audio settings is the most crucial step (which interface, is my headset good enough, etc)

A loopback mode would make this independant from any network-related stuff. I can imagine this two ways:

1. separate button: check it and local-loopback is enabled, uncheck and it is gone. Server-connection overwrites this. Checkbox and a level-regulator are available in settings dialog.
2. make this default disconnected behaviour: having a loopback active in disconnected state makes the transition to "connected" more continuous, since my own sound was already there. A "client-stream" dialog is shown in the main window just as if you were connected to a server with only you as client.

(This would also solve issues with running Discord in parallel to jamulus, where in "disconnected" state the Discord-Sound is unavailable, after connecting to a Jamulus-Server the Discord-Sound is available again. Inconvenient for remote tech-support)

This goes in line with the request to have Sound-Level display in disconnected state, but takes it further to also outputting the local input to the local output for system-setup before joining sessions & servers,

[nefarius2001]

Related to #712

also I see a benefit in telling local and network related buffet underruns apart.

Please state if such feature is actively discouraged, or just not interesting but will be accepted if implemented by someone.

[WolfganP]

I really see value in this feature request, as a local loop (ie jamulus client getting audio from the audio device, generate the packets, loopback and decode them and play on the audio interface) will help new users to make sure everything local is working (and avoid audio test with local audio device loopback, which doesn't guarantee is picked up by jamulus later and/or going to the server).
And it will certainly provide a more seamless transition to going online.
Good one!

[dcorson-ticino-com]

My experience getting people up-and-running is that the problem is getting the input volume set correctly, not using a server to get the loop-back. There are enough empty servers or use the server you are planning on joining.
Of course this would be a nice feature, but I'm not sure it will really help getting people set up correctly.

[ghost]

Note that it is normal for a local client to connect to the loopback interface (localhost 127.0.0.1) when you run a local server (do not use the server's external ip-address because it causes unnecessary ip traffic in this case).
This is already done with: Jamulus client :: Connect :: Server Address > 127.0.0.1
Problem Solved.

[nefarius2001]

Problem Solved.

I give support to some choire members at the moment, with quite mixed level of IT skills. That is where my focus on "VERY simple to explain/test" comes from. For myself, or one close friend: local server, no problem. Remotely on the phone with several group members one after the other: no way.

[gene96817]

I strongly support local loopback. This would greatly help getting non-technical users (many musicians) running. I promote to my new users a pre-first-jam, self-test. The local loopback would make self-test much easier.

Secondly, most users struggle with the ASIO configuration choices. The local loopback will allow the "try all the options and see what works" much more successful. Sadly, I am oftenly stuck with try all the options because the user cannot parse the language and meaning of each option.

[gilgongo]

I'm guessing this would have to be presented as a "test audio" feature as any attempt to explain local loopback would probably be horribly confusing ("Connect to myself"). And as @gene96817 points out, it would probably be most useful too in the context of picking the right device from ASIO.

[ann0see]

I requested something like this somewhere else. Would it be possible to add a button or similar which starts a localhost server and automatically? I think so.

[gene96817]

For the users that need the most help, I don't even want to be talking about a localhost server.

[ann0see]

Sure. Therefore an easily accessible button would be great. This would automatically start a server and connect the client to it.

[gene96817]

Ok... as long as the local server is totally invisible and does not need any support. I don't need one more piece of technology to explain and support.

Does this mean that every new user has to install the server? I don't even want to discuss this.

[ann0see]

As far as I understand, the server is just another Jamulus instance started with -s

[nefarius2001]

For the users that need the most help, I don't even want to be talking about a localhost server.

that is the main point.
Absolutely no room for errors in „first step“ problem-solving features

[gilgongo]

Something like this? So you'd check the box and then do whatever was needed?

I guess there would need to be a "Test mode" warning on the mixer panel.

[gilgongo]

Incidentally, if an artificial delay could be incorporated into the loopback, this idea could be combined with a test for whether you are listening to the correct sound (that is, from the server), as per this test.

[storeilly]

I'd like to add my vote for a local loopback test, I've just solved an issue for a chorister that was firewall related. Local loopback (without including a server) would have verified their sound configuration was in fact ok and saved them a few hours of troubleshooting.

[WolfganP]

In fact this Audio Loop Test may be added as an Onboarding/First Time User Experience step

[ghost]

Using a text editor in Windows or Linux, make a file named jam-loop.bat
containing the following text:
Jamulus -s -d & Jamulus -c 127.0.0.1

Make the file executable.
Make a desktop shortcut to jam-loop.bat

**** user does this ****
Double click on the desktop shortcut (the button)
Do the sound setup.
Use mouse to exit the two Jamulus applications that launched.
Join a session with Jamulus.

Problem Solved.

[gene96817]

****. Problem Solved
Ok, now we have all the tech needed to solve the problem.
We now need to help the non-technical users.
Could we put a button in the Settings window to start and stop the loopback test?

[gilgongo]

In fact this Audio Loop Test may be added as an Onboarding/First Time User Experience step

There's a test mentioned on Troubleshooting page but it's not as good as the the one I linked to so I might replace that. We are also in the middle of a large discussion about re-writing the getting started and onboarding docs (possibly merging the two) so could add this audio test to that.

[gilgongo]

Just an admin note on this ticket: we're trying to make items in the Issues list reasonably clearly defined specs for work that people can pick up. So, @nefarius2001 If you can adjust your original ticket to reflect any modifications to the idea, and get it into a description that would allow development to start and possibly a PR to be reviewed, please can you do so?

Thanks.

See also #991

[gilgongo]

Moving to discussion until we can get a spec on this.