With order of operations here, and track->volume being in range 0...256, I
don't think this will work anyway. volume of 255 of less will cause the
sample to be 0, and 256 the original value.
On Wed, 8 May 2019, m...@netbsd.org wrote:
Is there some scenario where this made a difference?
it sounds like an optimization that a compiler should already do
5234:#if defined(AUDIO_USE_C_IMPLEMENTATION_DEFINED_BEHAVIOR) &&
defined(__GNUC__)
5235- *d++ += ((aint2_t)*s++) * track->volume >> 8;
5236-#else
5237- *d++ += ((aint2_t)*s++) * track->volume / 256;
5238-#endif
