scummvm/scummvm — comment on commit 375047b72969fb4560cb7269134d586ff3baff31
File: engines/scumm/player_appleII.h line 152
By tobigun:

Thanks for the hint, MSVC did not produce such a warning.

Using frac_t is a nice idea, I did not know that it exists. It is odd that Player_V2::readBuffer() uses its own FIXP_SHIFT instead of frac_t.

1. A fractional part of 7 bits was choosen to have a bigger integral part, because more fractional precision will probably not provide any audible benefit.
The max. (integral part) value used for param "cycles" in addCycles() is 89471 (generated by Player_AppleII::wait()) so a 16.16 fixed point type is not big enough here. As an (ugly?) workaround "generateSamples(11 + count*(8 + 5 * interval))" could be split into two or more calls and the parameter type of generateSamples() and addCycles() should then be changed to uint16 (or frac_t).

2. The above is only a problem for cyclesFP. _cyclesPerSample, _missingCycles and _sampleCyclesSum only have a max. integral value of about 46 at 22.05 kHz and even less for higher rates.

3. But there is another problem with 16.16 fixed point in line:
addSampleToBuffer(2*32767 * _sampleCyclesSumFP / _cyclesPerSampleFP - 32767);
As this approx. equals "(_sampleCyclesSumFP << 16) / _cyclesPerSampleFP - 32767" the integral part will be shifted 16+16=32 bits in the multiplication part and hence will be ignored. Using a double type calculation solves this problem:
addSampleToBuffer(32767 * (2.0 * fracToDouble(_sampleCyclesSum) / fracToDouble(_cyclesPerSample) - 1.0));

So using frac_t in its current state does not seem to work at least not without workarounds for problem (1).