[BUG] unix squeak sound playing freeze

John.Maloney at disney.com John.Maloney at disney.com
Sat Sep 8 02:39:20 UTC 2001


Matthew,

I appreciate your detective work and your interest in this issue. However...

Given that the image already handles platforms that don't support sound,
I don't think we really need change the current SoundPlayer code.
It works fine on VM's with real sound support and it fails gracefully
on VM's without sound support. The problem you encountered seems to
be the result of the VM trying to simulate a sort of /dev/null sound driver,
which simply isn't necessary any more.

Incidentally, there is now an option that causes the SoundPlayer to shut
down when there are no sounds to be played. This eliminates the (fairly
minimal) overhead of playing silence when there are no sounds to play.

The time lag that you mention is only a problem if you use large sound
buffers. We try to keep the buffer size below 200 milliseconds, but on
fast machines you can set it down to a mere 30 milliseconds or so. There's
experimental primitive that mixes sound into the sound buffer that's
already been queue up--the "quickstart" primitive--but I think it only
works on Macs. It's a little more complex that I'd like and the primitive
is definitely tricky to implement.

	-- John


At 4:38 PM -0600 9/7/01, Matthew McNaughton wrote:
>On Fri, 7 Sep 2001, Lex Spoon wrote:
>
>> On Fri, Sep 07, 2001 at 05:42:06AM -0600, Matthew McNaughton wrote:
>> > 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?
>> 
>> Good detective work!  A really simple solution, which you'll find in
>> all the sqUnixSound.c files on my patches page, is to fail the
>> start-playing primitive.  Nowadays, Squeak can already perfectly-well
>> handle the absence of a sound device at the image level, and so
>> simulating a NULL device isn't needed.  This fix is accomplished
>> simply by making snd_Start() call success(false).
>
>This is one of the first workarounds I found, but I don't like it.
>Allowing SoundPlayer to constantly write zeroes has a number of problems:
>
>- Even when sound hardware is available, SoundPlayer consumes CPU
>unnecessarily. I don't really notice it on my 1.1Ghz athlon, but the
>people discussing using Squeak on a PDA might.
>
>- When a sound is played, there can be a delay while the sound hardware
>finishes playing all those zeroes, if the driver is unable to mix new
>sounds into stuff that is already playing.
>
>Would it be a waste of time for me to improve SoundPlayer? If it worked
>well, would it be likely to make its way into the image? Who would I send
>the change set to?






More information about the Squeak-dev mailing list