Switch all audio sample processing to use floats instead of a mix of double and int16_t

[corrados]

Currently, we use 16 bit fixed point for the audio data. The mixing is done in double-precision.

If an audio card with 24 bit depth is used, 8 bits are not used by Jamulus. To improve the audio quality for very low signal levels and if the Jamulus user has an audio card supporting more than 16 bits, it makes sense to use floating point calculations for the audio signal processing.

The downside is that the processing time increases. On a Raspberry Pi Zero we get about 1 % higher CPU load.

Also, the well-tested and stable Windows ASIO interface must be significantly modified which is a stability risk for the Jamulus software.

It has to be checked that all other features work correctly after the change (e.g., the clipping indicator).

There is already a patch available which is currently reviewed and tested: #535

[pljones]

There's a script in tools that would probably be affected, too (tools/jamulus-jamexporter/src/bash/recover-recording.sh).

[drummer1154]

Currently, we use 16 bit fixed point for the audio data. The mixing is done in double-precision.

Just for correctness: I think int16_t is 16 bit integer, not fixed point, right?

[gilgongo]

Is done now?

[corrados]

No, this is still open. The question is if we really need this in Jamulus. My opinion is that we should keep the current implementation.

[corrados]

I still don't see a need for this for Jamulus. HPS has created his own online jam software HPSJam and uses all float there. So I'll close this issue now.