Ian and Colin,

I agree that primSoundInsertSamples:from:samplesOfLeadTime: is
a hack. It solved a problem we had on the Macs, but it's difficult
 to implement on most other platforms. I agree with your choice
to NOT implement it, especially if this would require adding sound
card dependent code (ugh!).

If you update your 2.3 image from the update server, you'll find that there
is now a preference that turns off the "start immediately" mechanism
by default (Preferences allowSoundQuickStart). The insert samples
primitive is never called unless you manually turn this on.

This feature will be in the 2.4 image, of course.

	-- John

P.S. At some point, I think we withdraw the "start immediately" mechanism
altogether. It isn't even necessary on G3 Macs, which allow a very short
(12 mSec) output buffer size.

Ian Piumarta <Ian.Piumarta at inria.fr> wrote:
> Unix Squeakers,
> 
> The good news: I was tidying up a few things and got a little carried away.
> I'm writing this message while Squeak on my Linux box plays a stereo bach
> fugue.  (And no pthreads, fork()s, or other similar stuff in sight. ;-)
> 
> The bad bews: the way OSS works makes insertSamplesLeadBlahBlah impossible
> to implement in a platform-independent manner.  (It can be done by using
> direct DMA and the trigger stuff, but that works ONLY on Linux and imposes
> the sound card's byte order and format on me -- sorry, but I refuse to make
> the Unix [remember: Unix > Linux] sound stuff platform and/or sound card
> dependent).
> 
> The ugly news: the image says I can return 0 from insertSamplesEtc(), so I
> do.  Shortly thereafter the SoundPlayer barfs up a subscript bounds error.
> 
> Any volunteers to fix the image?  (You'll need Linux and/or the OSS lib [which
> is available for Sparcs, Alphas, and maybe some others] to test it.  The
> relevant carrot is an avant-premiere of sqUnixSound.c. ;^)