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.