I'm glad a few people around here do - there seems to be a bewildering mix of things out there.

Looking at the assorted C code for soundplugin, sqUnixSound, sqUnixSoundALSA & SsqUnixSoundPulseAudio I see a bunch of places where pointer types don't agree and just maybe there are some problems there. The worst potential for pointer issues is avoided in practice because we never actually pass any value for startIndex other than 0 (the '1' used in all the Smalltalk is pre-decremented in SoundPlugin>primitiveSoundPlaySamples)

Both the ALSA & pulseaudio files appear to connect to the semaphore in a reasonable manner. Ther pulseaudio code is clearly long untouched and in need of a lot of tidying up and the addition of a number of new routines like sound_GetDefaultSoundPlayer - try using that prim and it just dumps you VM with extreme prejudice!

I think one of the really puzzling things right now is how does my older Pi setup *not* make such terrible noises? The scratch image & vm involved are *identical* to the ones on the newer-but-still-alsa Pi.

> On 2020-12-25, at 6:03 AM, Herbert König <herbertkoenig at gmx.net> wrote:
> 
> Hey you seem to know Linux's audio stuff.
> 
> Thanks!
> 
> Herbert
> 
> Am 25.12.2020 um 14:54 schrieb K K Subbu:
>> On 25/12/20 6:49 pm, Herbert König wrote:
>>> It would be cool if someone can implement Your suggestion on how to
>>> write Squeak's audio output buffers to a file because then I could
>>> discern if the whole mess gets created by Squeak or if the OS plays a
>>> role too.
>> 
>> You may use parec (sound capture to file) and paplay (file to sound
>> output) to test the audio subsystem of the OS to rule out any audio
>> driver or mixer configuration problems [1]. The corresponding ALSA
>> utilities are arecord and aplay. The mixer is alsamixer.
>> 
>> padsp acts as a relay between the older /dev/dsp (audio device under
>> OSS) and the newer /dev/snd/* (audio i/o devices).
>> 
>> [1] https://manpages.debian.org/testing/pulseaudio-utils/pacat.1.en.html
>> 
>> HTH .. Subbu
>> 
> 
> 
> 


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
When flying inverted, remember that down is up and up is expensive