07-31-2020, 06:59 PM
(This post was last modified: 07-31-2020, 07:29 PM by JeffLearman.)
You're right. I assumed 32-bit floating point and not 32-bit fixed point, because from a practical standpoint, 32-bit floating point is very useful and 32-bit fixed point is nearly useless. When you see a .WAV file that someone says is 32-bit PCM, chances are good that it's 32-bit floating point and not fixed point. But I didn't make a recording to verify.
Regarding resampling, JK has to resample, in many cases. It can only send audio to your soundcard at one sample rate. So, the question is, does it resample on the sending end or receiving end? There are pros and cons but my instinct would be to use a standard rate in the protocol, and then at each endpoint, resample as needed. The big benefit to that is that at the receiving end, you can sum first and resample once, rather than resample each input stream and then sum. In that case, there would be a preferred sample rate, the one used by the protocol.
But you're right; it seems that if there is a standard rate in the protocol, it should be encouraged. And if there isn't, one should be encouraged as an ad-hoc standard.
Regarding resampling, JK has to resample, in many cases. It can only send audio to your soundcard at one sample rate. So, the question is, does it resample on the sending end or receiving end? There are pros and cons but my instinct would be to use a standard rate in the protocol, and then at each endpoint, resample as needed. The big benefit to that is that at the receiving end, you can sum first and resample once, rather than resample each input stream and then sum. In that case, there would be a preferred sample rate, the one used by the protocol.
But you're right; it seems that if there is a standard rate in the protocol, it should be encouraged. And if there isn't, one should be encouraged as an ad-hoc standard.