I searched all method sources for 3276 and only found one suspicious
place in :
adjustVolumeTo: vol overMSecs: mSecs
     "Adjust the volume of this sound to the given volume, a number in
the range [0.0..1.0], over the given number of milliseconds. The volume
will be changed a little bit on each sample until the desired volume is
reached."

     | newScaledVol |

     self flag: #bob.        "I removed the upper limit to allow making
sounds louder. hmm..."

     newScaledVol := (32768.0 * vol) truncated.
"<------------------------------- might exceed 32767 if vol = 1.0 ->
wrap not clip"
     newScaledVol = scaledVol ifTrue: [^ self].

but changing that to 32767 didn't help. Also I didn't find the version
where Bob had not yet removed the limit (my oldest image being 3.6) so
that is most probably not the culprit. Also I looked at a lot of in
image code but didn't find anything.

Next step is to try to record the output before it goes to the OS and
see if the image or some primitive creates the problem.

Cheers,

Herbert



Am 27.12.2020 um 01:57 schrieb tim Rowledge:
>
>> 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
>
>
>