Compressor Effect / simple "Dynamic Processing" in Jamulus

[sunnypp]

Feature Description

Enhancing the Input Boost (1x ... 10x): What about giving the possibility to make the boost "smarter" in the sense that the "loud enough signals" won't be too amplified?

Background / Context

This may or may not be related to #1062 , in the sense that we want the sound to be amplified.

In my case my friends are joining Jamulus with a sub-optimal setup, as simple as a mobile phone with a wired earphone, or even just handheld it to their ears with a relatively low volume to have minimal feedback.

In such cases, they may need a Boost anywhere from 2x to 8x so the volume gets to the green/yellow level to match with others. Such boost is needed because of the fact that their sound input device is relatively far from the sound sources (imagining playing piano with 2 hands while singing with a wired earphone hanging mid air).

And it hurts our ears when someone sneezes with 8x, or there is an accidental phone drop. This inspires a feature, that we amplify "most" signals (that we want and need), while accidental loud noises (that are over a certain limit) won't be amplified as much. This may somehow resemble a simple Compressor audio effect.

Given that reverb is provided by Jamulus, and Input Boost too, so I guess it may be also appropriate to suggest providing a Compressor-like effect in Jamulus.

Usability / How would it work?

After some thoughts, here are 2 of the possibilities that may be usuable:

1. Make another text field numerical input (limit or threshold for compressors) and audio signals louder than that level would be compressed.

So the existing Input Boost would behave like the "limit" is set to 0 dB and nothing is "compressed".

2. Make a checkbox, so when checked, a curve is used instead for calculations instead of the existing simple multiplication.

A formula with an input boost level n with level of loudness x normalized to from 0 to 1 would be like -(1-x)^n+1. (so its slope at 0 would be n while its slope at 1 would be 0)

Technical implementation

It seems to me that the current input boost is handled in CClient::ProcessAudioDataIntern:

            vecsStereoSndCrd[j + 1] = static_cast<int16_t> ( iInputBoost * vecsStereoSndCrd[j + 1] );
            vecsStereoSndCrd[j]     = static_cast<int16_t> ( iInputBoost * vecsStereoSndCrd[j] );

As this looks cleanly decoupled / isolated, it seems I could try contribute too, though I haven't yet tried to build Jamulus on my machine.

Considering Jamulus has feedback detection, so that's why the suggestions are made intended to kept 0 dB as 0 dB to avoid breaking features that depends on 0 dB being hit on the meter.

---

What are your thoughts on the feature? Anyone also using Input Boost and suffering from unexpected loud noises that no one intended to make that happen?

Thanks for reading. And thanks for everyone here who contributes to the Jamulus community!

[ann0see]

I understand that this feature may be necessary for less ideal audio setups. (The real solution would be a better audio setup of course!)

A problem I see is that it's yet another feature which adds some complexity and must therefore be considered carefully (both from the UX and technical perspective).

Approach 1 sounds simpler but approach 2 could also work.
Are there audio technical advantages of one over the other one?

[ann0see]

Ok. But approach 1 would potentially need a branch which also incurs a cost.
I'd believe that the performance difference is negligible.
I'd go with approach 1 probably?

[sunnypp]

I'd go with approach 1 probably?

As a developer myself, is there anything that I could help?

---

Lemme derive the formula with approach 1, given that MIN < THRESHOLD <= MAX:

Let the output level be y and input level be x.
The "compressed" (flatter) line would pass through (MAX,MAX), and the point that is the intersection between y=kx and y=THRESHOLD, which is (THRESHOLD/k, THRESHOLD) (k is the input boost factor)

So we could derive the slope m as m = ( MAX - THRESHOLD ) / ( MAX - ( THRESHOLD / k ) ). (∆y/∆x)

The equation (using a slope-point form formula) would then be

    ( y - MAX ) / ( x - MAX ) = m
<=>                         y = m * ( x - MAX ) + MAX 
<=>                         y = MAX * ( 1 - m ) + m * x

which we can potentially save the first product and the value for slope before entering the loop to have negligible performance improvements on modern devices.

[ann0see]

As a developer myself, is there anything that I could help?

Sure. Check out https://github.com/jamulussoftware/jamulus/blob/main/CONTRIBUTING.md

I'm not sure if/how much algebraic optimization bring benefit here - But precomputation seems sensible - even though the compiler may already do that? Multiplications probably take more time than addition. But it's for sure platform/architecture dependent (I don't know the cost by heart).

[sunnypp]

I have just tried on my Mac and even though my OS is on 13.1, it still builds successfully (on a re-run). (It warned me that it was built to support 10.15 only. What a pleasant surprise!)

For the algorithm part, as I am not familiar with the compiler, I don't prefer building a simple program and inspect the assembly code to check if it is optimized. Probably I will do that (negligible-)optimization in code.

For the copywriting part (e.g. what text should be shown in the Settings), what is the common practice for this codebase when implementing a new feature? Do we separate the implementation of functionality and translations into different branches or? If you are ok with it, please give me an overview of what is likely to happen, from me writing code till it's merged.

Many thanks!

[ann0see]

You don't need to think too much about translations. This will be handled by the translators and maintainers. Just make sure to wrap text into tr().
As general rules for contribution - since we can't surely say how the process will work out for you:

1. Be aware that reviews of your PR can take a lot of time. Expect more than one month of review from multiple people and a lot of back and forth. Eventually it'll get in if everything is ok and approved by at least two maintainers. Don't be afraid to bump the PR.
2. Provide screenshots of GUI changes
3. Comment your code like the code around.
4. Open the PR quite soon once you got a decent version working to allow early review
5. Every code is GPL licensed (and see the exception for the potential iOS distribution waiver). Add yourself in the util.h file
6. Make yourself familiar with rebasing. Squash and force push changes at the end of the review with a descriptive commit message

[ann0see]

Just so you know: Please also read https://github.com/orgs/jamulussoftware/discussions/1294

Times change so we may be more or less strict on some features.