> On 2020-12-24, at 2:35 AM, Herbert König <herbertkoenig at gmx.net> wrote:
> 
> There's always a chance that the OS meddles with it too. Notably on
> Windows if you simultaneously play and record it looses buffers
> sometimes. And often it is the combination of application and OS.

Yah. It certainly isn't impossible that changes to the underlying libraries are causing issues; after, my original work on this was done six years ago and the basic sound related stuff may be 20 years old.

> 
> I didn't find the place where Squeak audio goes out to the OS but
> writing this to a (preferably .wav) file would give a chance to analyse
> what happens inside Squeak. If anybody can post the necessary changes I
> can do that and check.

I can see three plausible places where it might be smart to record things
a) copy the sound buffer samples as sent to the prim in the #playLoop method
b) copy the samples actually sent to the OS by the VM
c) copy the sound output by the OS

I suspect that somebody can point to an application to record the final output cleanly.

> 
> I will set up a Pi and record the audio (hardware) output with another
> computer to see the sum of the effects.

I was almost at the point of just aiming my iPhone at the screen.

> 
> Are the snippets in your original post those which produce the problem
> on a Pi? Would be more comparable then waggling the keyboard.

Yes and no; that code shows off how the volume level can drive things into a screeching mess.

Here is another snippet that seems to illustrate things a bit better - 

|snd volume |
volume:= 40.
10 timesRepeat: [
	snd := FMSound new.
	"250 milliSeconds wait."
	snd
		setPitch: (AbstractSound pitchForMIDIKey: 60)
		dur: 1000
		loudness: ((volume / 100.0) min: 1.0 max: 0.0).
	snd play.
	50 milliSeconds wait.
	snd stopGracefully.
	"250 milliSeconds wait."
	snd := FMSound new.
	snd
		setPitch: (AbstractSound pitchForMIDIKey: 58)
		dur: 1000
		loudness: ((volume / 100.0) min: 1.0 max: 0.0).
	snd play.
	50 milliSeconds wait.
	snd stopGracefully]

You might experiment with 
- the volume setting
- the variety of FMSound (organ1 includes an envelope or two to mix things up a bit)
- the commented out between-sound delay, which I used to try to avoid two sounds overlapping in order to test the hypothesis that mixing was messing up

And depending on the update level of your image, the "X milliSeconds wait" might need to be changed back to "(Delay forMIlliSeconds: X) wait" etc.

I get a strangely interesting effect that is probably suggesting something important (and that I'm not yet getting) with the between-sound delay used and set to 150 mS. It's as if there is some mangling of buffers going on. At 100mS it goes berserk; at 200 it sounds perfectly regular.

I'm going to indulge in some code scanning to try to spot changes made that might affect this. I'll be interested how you see, or rather hear, things.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
"Bother!" said Pooh, as Piglet pressed <START> on the Microwave...