Fix overflow mixing

[whatisor]

Mixing without overflow checking will cause static noise.

[januscla]

Thanks for your contribution, @whatisor! Please make sure you sign our CLA, as it's a required step before we can merge this.

[lminiero]

I think this may more easily be done in a single place, which is where we define the buffer we'll actually send, rather than in all places where we do a sum:

https://github.com/meetecho/janus-gateway/blob/master/src/plugins/janus_audiobridge.c#L8908-L8910

We use an int32 on purpose to do mixing, to allow us to go beyond, and do N-1 mixing effectively. My guess is that N-1 could be broken if the source is touched and the mix clipped.

[tmatth]

FWIW opus comes with a nice implementation to this end but it's for floating point audio:
https://gitlab.xiph.org/xiph/opus/-/blob/main/include/opus.h?ref_type=heads#L800

[lminiero]

FWIW opus comes with a nice implementation to this end but it's for floating point audio:
https://gitlab.xiph.org/xiph/opus/-/blob/main/include/opus.h?ref_type=heads#L800

Turning the samples to float and calling opus_encode_float instead might be an option, but that would be a transformation anyway, so it might be easier to do it ourselves with what we have.

[whatisor]

@lminiero You are correct, that is much more efficient because you already use int buffer for sum.
I think it works in my test.

[lminiero]

Added a few notes inline, thanks!

[lminiero]

To avoid risks of clashes, better to add a unique prefix to those defines, e.g. JANUS_AUDIOBRIDGE_SHRT_MAX_TUNED etc.

[lminiero]

Same thing for this function here, so something like janus_audiobridge_overflow_check.

As a side note, better to define sum as int32_t, as that's what the original sumBuffer is. A generic int should be fine in general anyway, but considering this could be compiled on different systems, better be explicit about it and avoid surprises.

[lminiero]

I think this looks good, in general, but is incomplete. At the moment this only smoothens the mix meant to be sent back to participants, but ignores the places where we do the same sum for the recording (L8839 in current master) and for RTP forwarders (L8969, L8994, L8999), meaning the audio could still be saturated there.