Thanks to Ned for telling me where to send this stuff.

Symptom:

If squeak is configured not to use sound at compile time on a unix system,
and you take an action that tries to play a sound, squeak will freeze up.
You can press Meta-Period, the user-interrupt key, to make it start again.

Fortunately I've found the reason, though not the solution. This happens
on Linux if I #undef HAVE_OSS in src/unix/sqUnixSound.c, and on Solaris
and OpenBSD systems without OSS installed.

Diagnosis:

In src/unix/sqUnixSound.c, HAVE_OSS will not be defined, so the dummy
low-level sound driver routines from lines 468 to 516 will be compiled.
These pretend to the upper levels that sound hardware is in fact
available, and discard whatever sounds are passed down. It will also
pretend in snd_AvailableSpace() that there is always room for more sound
data.

This becomes important in the image, in SoundPlayer>>playLoop. If there is
always space, then playLoop will sit in an infinite loop, continuously
writing zeroes to the sound device. On real sound hardware, the sound
driver's output buffer will fill up eventually and snd_AvailableSpace()
will return 0, so that the block [ReadyForBuffer wait] in playLoop will
eventually be executed.

Why does this infinite loop freeze the system? Because the SoundPlayer
process runs at UserInterruptPriority, so if it doesn't go to sleep
waiting for room in the sound device, nothing else will get to run.

Why does Meta-Period make the problem go away? Because
InputSensor>>userInterruptWatcher explicitly shuts down the SoundPlayer,
so that things are fine until the next time a sound is played and the
SoundPlayer process is restarted.

SoundPlayer should not be writing zeroes constantly. Is there some reason
it does this? Are there hardware platforms that will play static if you
don't keep them crammed full of zeroes?

Solution:

Implement a proper producer/consumer protocol on ActiveSounds, a class
variable of SoundPlayer. Are there any synchronization primitives beyond
Semaphore in the Squeak libraries? Things seem to get weird if I just
insert a Semaphore>>wait call inside a block passed to
Semaphore>>critical:.

I'll work on this over the next few weeks.

-- 
Matthew McNaughton <mcnaught at cs.ualberta.ca>