At 16:23 -0400 5/4/00, Bob Arning wrote:
>On Thu, 4 May 2000 15:54:28 -0400 "David N. Smith \(IBM\)" <dnsmith at watson.ibm.com> wrote:
>>However, when I run this a lot, playing four different sounds, sometimes a sound is played twice in a row, and on rare occasions it is played four times. They aren't just queuing up; the application never plays the same sound twice in a row. That is, I play A-B-C-A-B-C  and I might get A-B-C-A-B-B-C. The problem never repeats in the same place, and is rare, say 1 out of 20 times.
>
>Dave,
>
>I'll take a deeper look, but a quick possible explanation is this: the Mac VM uses two sound buffers so that it can be filling one while the SoundManager is playing the other. When the first buffer finishes, the other starts playing and Squeak can start refilling the first buffer with the next sound samples. If Squeak is delayed in doing that, the SoundManager will simply replay whatever is present from before. I have seen this happen when another Squeak process at the same (5) or higher priority prevents the SoundPlayer's PlayerProcess from the timely completion of its business. So some questions:
>
>1. Any other processes running at or above 5?
>2. Are the four sounds played concurrently or consecutively?
>3. From the time you issue "s play" for the first sound until that sound completes, what else is happening? Are you decoding the next sound? Have you tried waiting for one sound to finish before doing anything else? (I know that may not be what you might want ultimately, but it may help pinpoint things).
>
>Cheers,
>Bob

Bob:

1. I have no processes in my code and know of no others at priority 5 or above.

2. Sounds are played as a user interacts. For example, a user picks up (using D&D) a morph and there is a sound. She drops it in a special place and there is a second sound. When the right things are in the special place, there is a pause (using #step to time it) and yet another sound as the items redisplay themselves. Etc...

3. While the sounds play, there is interaction going on. The next sound is always read from disk just when an event is done that needs a sound; there is nothing fancy; all my contact with the sound system is in the method #playSoundName:, below. The files are small and reading them is fast and all I need is the sound to play while more goes on in the GUI.

For testing, I modified my play sound method to:

playSoundName: aName
	| snd |
	" TRWProtoSounds playSoundName: 'pop' "

Transcript cr; show: 'Play sound ', aName, ' ', Time millisecondClockValue printString.

	lastSound isNil ifFalse: [
		SoundPlayer waitUntilDonePlaying: lastSound ].

	(self soundNamesBuiltin includes: aName)
		ifTrue: [
			SoundPlayer stopReverb.
			SampledSound playSoundNamed: aName ]
		ifFalse: [
			snd := SampledSound fromAIFFfileNamed: FileDirectory default
				pathName, ':TRW:sounds:', aName, '.aif'.
			SoundPlayer stopReverb.
			snd playAndWaitUntilDone ].
	lastSound := name

It waits for the sound to finish. I select the example at the front and watch the transcript. It only writes one line even if I hear two or four sounds. I was very careful to just tap the Command-D key so that there was no chance of automatic key repeat.

Waiting for the sound to finish ruins the flow of the application, and I still get multiple sounds sometimes.

Thanks for your suggestions; any more ideas are greatly appreciated.

Dave
_______________________________
David N. Smith
IBM T J Watson Research Center
Hawthorne, NY
_______________________________
Any opinions or recommendations
herein are those of the author  
and not of his employer.