> On 2020-12-26, at 4:57 AM, Herbert König <herbertkoenig at gmx.net> wrote:
> 
> Tim, thanks for the recording.
> 
> No idea if that happens inside Squeak but basically clipping is not
> working. In the image instead of going from positive full-scale to
> negative full-scale the signal should just stay at the resp. full-scale.
> Instead of clipping 32767 + 1 to 32767  the code uses 32768 as being -
> full-scale (wraparound).  See pulse1PosWrap.png. 

Staring at the generated C code it looks possibly suspicious that we have

short int *aSoundBuffer; 
sqInt s; 
		if (leftVol > 0) {
			i = (2 * sliceIndex) - 1;
			s = (aSoundBuffer[i]) + ((sample * leftVol) / ScaleFactor);
			if (s > 0x7FFF) {
				s = 0x7FFF;
			}
			if (s < -32767) {
				s = -32767;
			}
			aSoundBuffer[i] = s;
		}
But surely no C compiler screws that up these days?

I added printfs to show when over/underflow happened and indeed it happens - duh. 

I've compared latest and ancient (as in ~2016 vintage) copies of SoundPlugin.c, SoundGenerationPlugin.c and sqUnixSoundALSA.c and found nothing that looks anything other than trivial changes - dates, some macros, etc.

There doesn't seem to be any place other than primitiveMixFMSound() that is involved in clipping sample values. None of the lowest level send-to-OS code looks to do any sort of casting or limiting.

I've even just for grins tried limiting the 's' value with a s & 0x3FFF just to see what happens. It sounds a bit strange but also seems to remove the clicks, so maybe there is something in it.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: BYEBYE: Store in Write-Only Storage