Allow Jack output above 0dBFS; do not clamp it at 0dBFS

[Attila Schler]

With Reaper - also with Ardour - signals above 0dBFS could be sent to Jack, and in my opinion Mixxx should allow this too. Then one can process, limit, etc his signal with other Jack enabled tools, DAWs, plugins, etc.

(Further, if one uses Mixxx with a controller probably he can record his set in 32bit without clipping above 0dBFS.)

If nothing used, then the signal will be clamped probably by Jack or by ALSA. I don’t know but the signal will be clamped somewhere and nothing will crash.

See this issue brought up here:
https://mixxx.discourse.group/t/jack-out-clipping-at-0dbfs/24069/15

And limiter questions like this could be solved also in Jack with enabling output above 0dBFS (and for example with x42-dpl, ~1.2ms latency@44.1k):
https://mixxx.discourse.group/t/clipping-problem-on-some-specific-tracks/24120

[Daniel Schürmann (daschuer)]

If this works, nice. But we need to verify that there is at least a clamping done in Jack.
If not we will hear an overflow that sounds like a high pitch noise that likely blows your tweeter.

[Be (be.ing)]

I asked the JACK maintainer (falktx) about this on IRC. He said that JACK does not do any clamping, but he thought ALSA may take care of that.

[Be (be.ing)]

The clamping was added in
https://github.com/mixxxdj/mixxx/commit/1db7b803764eccd6f22ef3f380cf1b288f0a93c8
from
https://github.com/mixxxdj/mixxx/pull/219

Unfortunately there is no information in the commit message, code comment, or PR discussion about the reasoning for adding the clamping. I presumed that it was necessary to avoid creating signals that speakers couldn't handle. Then I found this old bug:
https://bugs.launchpad.net/mixxx/+bug/1302361
So it seems there used to be clipping within Mixxx for no clear reason. This was modified in https://github.com/mixxxdj/mixxx/pull/229 to move it to Mixxx's output. But it doesn't seem anybody questioned if there was a need for any clamping at all. I would think that the operating systems would take care of clamping to 0 dBFS before sending the samples to the audio interface. I have never heard of someone having a problem caused by software outputting samples > 0 dBFS.

[Be (be.ing)]

The old EngineClipping class which was removed in https://github.com/mixxxdj/mixxx/pull/229 goes all the way back to 2002, where it looks like it did clamping using some formula and magic constants which have no explanation:

https://github.com/mixxxdj/mixxx/blob/953020fc5bae4ef3fcc44a5cf5359f9da395ab1e/mixxx/src/engineclipping.cpp#L25

I think it would be worth a try to remove the clamping entirely and find out if it causes issues on each OS with each sound API.

[Be (be.ing)]

Ah, that magic constant max_amp came from Mixxx previously working in the range of [-SHRT_MAX, SHRT_MAX]... why it considered samples > 80% of that maximum as clipping, I don't know.
https://bugs.launchpad.net/mixxx/+bug/1204039

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/10647