Bob and Dave,

This reminded me of another possible "gotcha" about sound. This
one applies ONLY to Macintosh Powerbooks, especially G3 Powerbooks,
which is what Dave has.

The symptom is a hiccup in the sound shortly after you've done a
"doit", such as the one you were using to play the clink sound.

The reason is that the Mac OS grabs control from the Squeak VM for
longer than one sound buffer's worth of time. Why does it do this?
Only someone with knowledge of the Mac OS internals could say for
sure, but my theory is that the G3 tries to park the disk head
whenever the disk hasn't been used for a second or so. Before it
does so, it first makes sure that any file system state that was
buffered in RAM gets written out. (In Unix, this is called
"sync-ing" the file system, I believe.) The file sync operation
is not interruptable (by Squeak, at least) and it can keep the
next sound buffer from going out in time.

How to avoid it? You can make the sound player buffer longer, as Bob
suggested. Or, you can avoid writing to the disk. Or, you can write
the disk really often, to keep the OS from deciding to park the
disk heads. Note that it is the write to the Squeak log file that
makes "do-its" tickle the behavior. Actions triggered by, say,
Morphic drag and drop or button clicks won't have this problem.

I'm not sure if reading a file will trigger the disk sync-ing. But
if the disk has spun done, attempting to read a file can cause a
REALLY long interruption to Squeak while the disk spins up. This
could be the problem with reading sounds from AIFF files.

By the way, many thanks to you, Bob, (and also John Mcintosh, Karl,
and Bruce) for jumping in to help Dave with this problem.

	-- John

P.S. The usual incremental GC is typically well under 10 milliseconds,
and doesn't bother the sound player process at all. (It could if you
were using tiny, 10 msec buffers. But the Mac OS doesn't properly
support buffers that small.)


At 3:08 PM -0400 5/5/00, Bob Arning wrote:
>On Fri, 5 May 2000 13:10:19 -0400 "David N. Smith \(IBM\)" <dnsmith at watson.ibm.com> wrote:
>>(later) Try this:
>>
>>	SampledSound playSoundNamed: 'clink'
>>
>>Select it, and press Command-D repeatedly but carefully. It shows the same property: every so often it plays multiple sounds with one key press. (I have reverb off.) This is a builtin sound and does not go thru my code at all. We got ghosts!
>
>Dave,
>
>Yep, I hear them too. The thing that is critical to avoiding sounds repeating, either in whole (for short sounds) or in part, is how quickly SoundPlayer class>>playLoop can cycle around to fill the buffer with the next sound samples (or silence for the two passes after the last sound is added). I put some logging in to see how often this was happening. When I heard a repeat (full or partial), there was generally a longer than usual delay in one or two of these cycles. Very often there was an incremental garbage collection that occurred in that interval, but I can't convince myself that this consumed enough time. To test that this longer interval was related, I played with setting the BufferMSecs to 80 and to 300. (Did you remember to "SoundPlayer initialize; shutDown; startUp" after changing the source? I forgot more than once.) At 80 msec I hear some repeat almost every time. At 300 I did not hear an error in 20 tries. I can't tell at this point whether it is Squeak being to!
!
!
!
o busy to get back to the sound player loop quickly enough or whether the MacOS is occasionally doing some of its own work, but the time does seem to make a difference to me. BTW: this was on a G3/400 desktop - you might want to go even higher than 300 msec for a PowerBook.
>
>Cheers,
>Bob