BASOP applications and floating-point code

Basic info

• BASOP 97a22a9d

Bug description

Applications, common API types and utilities (lib_util files) in the BASOP framework use floating-point arithmetic. This might not necessarily be an issue in my view. On the other hand, it might be an intention by which we could end up with frameworks in which application + utility files and common_api_types.h could be identical between FLP and BASOP frameworks.

This would, in my opinion, simplify the integration of CRs and fixes and help in understanding the codec integration for future integrators. I did an investigation into how much the application and utility files currently differ between BASOP and FLP and what this approach would mean:

1. The API function names and parameters need to be the same between FLP and BASOP, which is already usually the case
2. The parameter hIvasDec->pcmType does not exist in BASOP while it is always set to IVAS_DEC_PCM_INT16 in FLP.  It can thus be either removed from FLP or introduced into BASOP.
3. common_api_types.h would need to always contain integer data type parameters for their float counterparts. This is already the case for many parameters in the BASOP framework.
4. Utilities would need to fill both float and integer values of the same parameter
5. Currently, we assume that external files like metadata or trajectories contain float numbers. I am not sure whether this is foreseen as a final state, but I can imagine so.
6. In renderer.c, float data buffers used for processing are defined and allocated in the application instead of the library. They would thus need to be defined in the codec library similarly to how it is done, e.g., in the decoder.

Another option is, of course, to use purely BASOP code in the BASOP application and utility files and also external files, which would mean to convert them from float to BASOP.