Refactor Input boost to be easily ifdef'd out

[ann0see]

What is the current behaviour and why should it be changed?

The input boost feature is currently coupled too strong to the client. This should be refactored with the goal to be able to compile Jamulus without it.

Describe possible approaches

Introduce a class similar to the Reverb class that applies input boost.

Suggestion would be an architecture that allows setting the gain, getting the gain and applying the gain to a channel. We could abstract this in a general "ClientEffect" or similar class which could also handle the "pan".

Has this feature been discussed and generally agreed?

No. This issue should serve as defining the spec.

Cc: @pljones @dingodoppelt

[mcfnord]

AI told me: "the live open question across all four threads is really: does #3844's ifdef architecture satisfy pljones's objection well enough that #3843 gets approved, or does the feature still get argued into removal on its own merits regardless of build-time gating?"

It sounds like you're really saying easily ifdef'd in, and the default build would exclude it. It does seem like a niche' and corner case. Within that case, the profile is of cheap laptops using cheap microphones to get a group online. Or an individual, sure. My feelings are that ASIO4ALL is not, really, a viable usage scenario long-term, and so a feature designed like a Band-aid on ASIO4ALL is not something we should care a lot about. So I see the case for isolating the feature as you've suggested, and shipping without it by default.

[ann0see]

My feelings are that ASIO4ALL is not, really, a viable usage scenario long-term, and so a feature designed like a Band-aid on ASIO4ALL is not something we should care a lot about.

It's about first time user experience. Users with bad gear should still be able to use Jamulus. Not everyone is willing to spend any money on gear to get started. The bar of entry is already high due to the bad state Windows low latency is in. We should not make it higher.

[dingodoppelt]

My feelings are that ASIO4ALL is not, really, a viable usage scenario long-term, and so a feature designed like a Band-aid on ASIO4ALL is not something we should care a lot about.

It's about first time user experience. Users with bad gear should still be able to use Jamulus. Not everyone is willing to spend any money on gear to get started. The bar of entry is already high due to the bad state Windows low latency is in. We should not make it higher.

This was kind of a valid point for the pandemic, where some people (mostly hobbyists) were using unfit hardware.
Nowadays I think we can get rid of that feature entirely and furthermore advise users to use specialized hardware (which most users do already).

What makes it harder to ifdef is the fact that the UI is static and we would have to create more code to hide the elements when ifdef'd out. Same applies to the reverb feature and any other feature with a UI entanglement.

[ann0see]

Fair point. Nevertheless having some if X hide Y has less attack surface/bug surface than more complex code.

[ann0see]

This was kind of a valid point for the pandemic, where some people (mostly hobbyists) were using unfit hardware.

First time UX still matters IMO. If you have great but unusable software you loose people. That’s bad style.

The same reason lies behind fixing the ASIO4ALL hang. The hang is technically not severe if someone uses "real" gear.

[pljones]

The main problem I have with this is that it's a source of more issues than it solves. I've never heard of anyone finding it useful. It's usually going to be raising an already too high noise floor to overpowering levels. I'm really not sure it does improve new user experience.

[dingodoppelt]

The main problem I have with this is that it's a source of more issues than it solves. I've never heard of anyone finding it useful. It's usually going to be raising an already too high noise floor to overpowering levels. I'm really not sure it does improve new user experience.

I share your feelings about the feature and would like to add, that I'd like to go as far as to say that I'd probably leave a server where somebody would be using this feature just because of fidelity issues.

[dingodoppelt]

The same proposal popped up in #3787 in respect to the reverb plugin.
It still needs review but the Input Boost UI elements can be hidden the same way.