So, I'll use a float variable instead the fixed 1.0f and set it according to the requested output format.
Agreed.
@yesgrey3
I am considering to get rid of the "24 bit PCM padded to 32 bit" output selection. Instead I want to always use the "24 bit PCM padded to 32 bit" method if the user selects 32bit PCM as output.
I have performed some tests with my soundcard and a little software tool created by RME, Digicheck, to try to understand how the driver communication works... I think I did.
Yes, I think you should remove it, but, instead of always perform the "24 bit PCM padded to 32 bit", you should leave it as it is, converting the float to 32 bit PCM, that's the best option.
I realized that the drivers communication use a very basic method. They simply use the MSb they need and ignore the rest. So, if I feed 32 bit PCM to a 16bit soundcard, it will use only the 16 MSb. If I feed 32 bit PCM to a 24 bit soundcard, it will use only the 24 MSb and ignore the 8 LSb.
1.) If user inputs 32bit int and outputs 32bit int nothing will happen. Converting 32bit int to 24bit int via FP doesn't make much sense.
Agreed. 32 bit PCM -> 32 bit PCM should be direct (when resampling is disabled), but if you keep it as it is now, it would not be an issue. Read below.
2.) If user inputs 32bit and resamples precision will be lost because of the FP conversion anyway.
Right.
3.) If user converts anything else to 32bit PCM, conversion is done via FP, so a higher precision than 24bit doesn't make any sense.
No. A higher precision than 24bit does make sense, and that's the reason I think you should drop the padding and keep the float to 32 bit PCM as it currently is. I know I have stated that previously, but now I have realized I was wrong.
Let me explain...
I was attached to the idea that a 24bit significand in FP has the same meaning as 24 bit in integer, but it's not. The 24 bit significand means that at any exponent used, we have always a precision of 7 decimal places.
With 24 bit PCM, we can only represent the values 1, 2, 3, ... we cannot represent 1.2, or 1.246, but with 32 FP we can, hence we have higher precision at low values.
So, I think we should perform the conversion from float to PCM32 and simply drop the padding idea, because if we convert to 24 bit PCM and pad to 32 bit PCM we will lose precision at lower values.
In reality, we could perfectly live with the "24 bit PCM padded to 32 bit" because there is not (and probably never will) any soundcards with more than 24 bit DACs, so the 8 LSb will always be dropped, but it doesn't hurt to have the data there...
Pros for going with float->24 bit PCM padded to 32 bit:
-Faster conversion
-In case we're storing the data in a file it will compress better
-No soundcards higher than 24 bit
Cons:
-details lost at the lowest 8 bits
-if one day 32 bit soundcards are available you will be asked to remove the padding option...
Sorry for the constant changing in some of my ideas, but I'm somewhere in the middle of the learning curve, so mistakes do have to happen...