Catching up on the series, I found my wave/physics knowledge a bit rusty to say the least when I was going through the first audio videos. Stuff like Period, Frequency/Pitch, Amplitude/Volume, Wavelength, Waveheight, etc got me confused.
So I wanted to share a few resources that helped me get back in shape, just in case somebody else is stuck or struggling the same. Back to school :D
0- Why is Casey calling this variable 'WavePeriod' when it's actually just 'SamplesPerCycle'. Because he's getting it by dividing SamplesPerSecond over ToneHZ (CyclesPerSecond). So...
How is he considering that a 'period'? What I understood from the resources above, is that a period is the 'time' it takes to do a wavelength/finish a complete cycle.
1- When implementing the sound mixer, Casey mentioned that we should do the addition in float space, and cast back to int16 to avoid clipping. Well, doesn't that actually still clip? I mean, instead of adding the amplitudes in 16-bit space we're adding in 32-bit float space and casting back to 16-bit space, doesn't that produce the same result?
Adding values in 16-bit type won't work because you'll overflow. Try adding two samples: 20000 and 20000. What value you will get in signed 16-bit type? Signed 16-bit type can contain values only in [-32768..32767]. 20000+20000 is 40000, that will overflow into negative values. Typically you prevent it by clipping to min and max value - 40000 result will clip to 32767. Adding in floats gives much bigger range until it will start overflowing (to infinity). In practice float range is fine and you won't be adding so many sounds to overflow.
I know about the ranges. But what I'm saying is, 20000.0f + 20000.0f in float is 40000.0f right? Now cast 40000 to int16, don't we still get 32767? Unless I'm missing/misunderstanding something.
Yes, that's correct. If you have only these two values, then you'll get 32767 in both cases.
But if you are adding these three values: 20000, 20000, -20000. The result obviously is 20000, right?
With int16 calculations will go like this:
20000 + 20000 = 40000, clip to 32767.
32767 - 20000 = 12767. Result has wrong value!
With float calculations will go like this:
20000.0f + 20000.0f = 40000.0f
40000.0f - 20000.0f = 20000.0f
Convert 20000.0f to int16 and you get 20000. The result now is correct.
For floats clipping occurs only on final value, not on each intermediate step.
Of course it's not ideal, but not as bad as if you would clip for each intermediate value.
If you don't normalize audio to [-1.0..1.0] range when storing samples as float you could use just int32. No need for float.
Oh snap! Eye of the mmozeiko :D So it's basically reducing the _accumulating_ errors due to addition to a single failure point and not _all_ the errors.