Jamulus feedback protection, possible to turn off?

[harmonk]

Hi All,
Using Jamulus and like it.
One thing i would see changed: Whenever there is a loud sudden noise, bump the mic for example, the feedback protection kicks in, i get a popup window and everything is muted. So three clicks: wondow close, 'mute all', my channel mute. Every time.
I don't need this, so i wonder if there is any way to turn this off? I can't find any way.
This is not the same as 'feedback protection' in the advanced setting. That is already turned off.
Thanks for any thoughts about this.

[npostavs]

This is not the same as 'feedback protection' in the advanced setting. That is already turned off.

If it's not that, then it sounds like a bug. What does the popup window say?

[pljones]

Same process -- in your fork, branch for the fix, make the change and push, then raise the pull request for review.

[npostavs]

@JohannesBrx I had the idea this morning that instead of bDetectFeedback being a boolean and turning it off with a timer, it could be a timestamp and only be considered enabled if it's within 3 seconds of current time. Then you wouldn't need the extra timer at all.

[pljones]

Better to store "three seconds from now" at connect and then bypass the check if "now is greater than cutoff". That stops you doing the calculation each time. The bool check still is simpler, of course.

[pljones]

One thing I've wondered is whether "connect" is being managed properly. Is there any way to check whether the client "thinks it's connecting" more often than one would imagine? (I've not looked at the code -- if this only happens when the user deliberately connects, it shouldn't be an issue but if it happens when the connection succeeds, then that might be being triggered in unexpected ways.)

[JohannesBrx]

I opened PR #2096 with a quick fix which redundantly checks the feedback detection enable state.

@npostavs: I did not yet have spare time to implement the solution with the timestamp.

[JacquesFreud]

Since about a week on some (I think not all, but I am not sure) servers (i.e. Die Insel, Genre 1 or MTKS.F, genre 2) feedback protection kicks in way too fast. A sudden laugh, a handclap, a guitar that starts soloing, a keyboard, vocals - many sounds that were normally accepted before, all of a sudden lead to muting.
This happens both when you selected Feedback Protection in your settings or not. This has nothing to do with initial startup of people who forgot to turn off their speakers or made some other mistake. It started happening about a week ago and not when this feature was introduced in version 3.8.0
Anybody with a solution?

[softins]

I have just managed to reproduce the above behaviour reliably, by temporarily adding an initialisation of bDetectFeedback to true in CClientDlg::CClientDlg(). Then the described behaviour occurs during the first connection, but not during subsequent connections within the same run of the program.

Note that for current versions of Jamulus, if the feedback detection is ENABLED in settings, then this bug can never occur.

[softins]

So this means that after starting the program, and connecting for the first time to a server, the problem may or may not occur, depending on whether the uninitialised bDetectFeedback happens to be zero or non-zero. After disconnecting from the server, it should then be possible to connect to any server without the problem occurring for the rest of the time the program is running. Exiting and restarting the program will allow the issue to occur again for the duration of the next connection. @harmonk please could you test and confirm this?

Also @JacquesFreud ?

[JacquesFreud]

Ooh sorry, there were no reactions for a while and now all of a sudden a whole lot.
Let me start out by saying that I reinstalled 3.7.0 and got rid of the feedback protection. But that is not what you tech guts are after, of course. The servers that hurt me most were Die Insel in Genre 1 and MTKS.F in genre 2. It could very well be that by changing to another server solved my problem, because I have thought quite often that the problem occurred with some servers and not on others…

[softins]

It could very well be that by changing to another server solved my problem, because I have thought quite often that the problem occurred with some servers and not on others…

Thanks, but what solved your problem was disconnecting and then reconnecting to a server. It can only occur during the first connection after starting the program.

[JacquesFreud]

Indeed! Thanks for figuring this all out!

[ghost]

I believe there may be multiple bugs in this code as suggested above.
And also in:
/home/USER/.config/Jamulus/Jamulus.ini
Where more than one variable may be saved because of updating an old version of Jamulus.ini

[rdica]

What are the vars in the ini file that conflict now?

[rdica]

@DavidSavinkoff You never responded, what vars would conflict?

[softins]

Where more than one variable may be saved because of updating an old version of Jamulus.ini

I think you will find this cannot occur. The Jamulus.ini file is written from scratch when the program exits, and will just contain the current set of variables. Old variables from previous versions might be understood for compatibility when reading the ini file at startup, but will not be written out again on exit.

[JacquesFreud]

I removed the 'jamulus.ini' file and started up Jamulus. The first handclaps I tried were quite promising, David! I will see how things develop in the upcoming days and will report back as soon as I dare to make more definitive conclusions. Thanks!

[JacquesFreud]

First conclusion: removing the jamulus.ini did not solve the problem. Changing to a different server (leaving my volume settings at the same level) did help. So the problem may be a combination of Jamulus and some servers you use it on.

[rdica]

Can you note the version of Jamulus the servers are running? You can get that info from https://explorer.jamulus.io

[JacquesFreud]

This by no means a representative measuring (only three servers I tried and looked at): one that had the feedback protection kick in too fast: 3.8.0; one that was okay: 3.6.2 and another one that failed me on the feedback: 3.6.2
So version number seems not to be the problem...

[softins]

This by no means a representative measuring (only three servers I tried and looked at): one that had the feedback protection kick in too fast: 3.8.0; one that was okay: 3.6.2 and another one that failed me on the feedback: 3.6.2 So version number seems not to be the problem...

If there are specific servers that reliably cause the problem, could you mention one or two of them, so that we could test and reproduce the problem too?

[softins]

This by no means a representative measuring (only three servers I tried and looked at): one that had the feedback protection kick in too fast: 3.8.0; one that was okay: 3.6.2 and another one that failed me on the feedback: 3.6.2 So version number seems not to be the problem...

If there are specific servers that reliably cause the problem, could you mention one or two of them, so that we could test and reproduce the problem too?

Don't worry about that, but please see my reply above at #2066 (reply in thread)

[JacquesFreud]

Die Insel in Genre 1 and MTKS.F in Genre 2. Hope this helps.

[softins]

This bug is fixed in #2120

[JacquesFreud]

Does this mean I can safely go back to 3.8.1 or do I need to wait for an update?

[softins]

3.8.1 does not contain the fix. The next release will, although no timeframe for the next release has been decided.

If you leave feedback detection enabled, the problem will never occur: the test for loudness will only happen during the first 3 seconds of a connection. So with that setting, you can safely use 3.8.1.

[JacquesFreud]

Thanks, you wonderful people!

[harmonk]

I see this only now. But thanks! So i will turn on feedback protection, and then wait for the next update which will contain the fix.

[ann0see]

Yes. The next release should be around the corner

[hoffie]

There's also a pre-release here which contains the fix already:
https://github.com/jamulussoftware/jamulus/releases/tag/r3.8.1devNightly1

(The pre-release might be missing some translations though)