SampleFormat clarifications: range of values

[hugovdm]

Looking at this: https://docs.rs/cpal/0.13.1/cpal/enum.SampleFormat.html

I see for F32, "The boundaries are (-1.0, 1.0)." If I run the feedback example on my Linux-running laptop, without JACK, the highest value I seem to read from input is 0.302, not 1.0 - I'm curious why that is, whether or not it is a bug, or whether this behaviour can be documented in a good place. (It clips at 0.302.) When using JACK, I get 1.0 as expected.

(Potentially, while touching such documentation, I see an explanation of U16: "The value 0 corresponds to 32768." - and think there's some room for improvement in how this is worded too. I suppose if this isn't clear to the reader of this Issue, and I want to make a specific improvement suggestion, I might as well do it as a Pull Request?)

[mitchmindtree]

Thanks @hugovdm, I agree some clarification on this would be welcome! I think #420, #414 are also related and might be interesting to read first, as there has been some discussion about potentially using the dasp_sample crate for local sample format types.

[HEnquist]

IMO the conversions int <-> float are all weird!
https://github.com/RustAudio/cpal/blob/master/src/samples_formats.rs#L81
In order to reach a max value of +1.0 instead of 0.999..., positive and negative values are treated differently. This give a small nonlinearity and I think this is wrong. I'll describe how I think it should be done using i8 (range -128 to +127) as a simple example.

• i8 to float: value as f32 / 128. Resulting range: -1.0 to +0.992.
• float to i8: value*128, if below -128 or above +127 set to those values, then cast to i8.
  This way, a 24-bit int can be losslessly converted to float and back again.