Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!tut.cis.ohio-state.edu!ucsd!rutgers!mcnc!uvaarpa!murdoch!astsun9.astro.Virginia.EDU!cak3g
From: cak3g@astsun9.astro.Virginia.EDU (Colin Klipsch)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Synchronous sounds using the Sound Manager
Summary: Careful with SndNewChannel!
Message-ID: <1990Jun5.225616.5420@murdoch.acc.Virginia.EDU>
Date: 5 Jun 90 22:56:16 GMT
References: <1990Jun4.020601.9644@msuinfo.cl.msu.edu> <30976@ut-emx.UUCP> <8548@goofy.Apple.COM>
Sender: news@murdoch.acc.Virginia.EDU
Organization: University of Virginia
Lines: 64

In article <8548@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes:
>In article <30976@ut-emx.UUCP> wras@walt.cc.utexas.edu (Steve Mariotti) 
>writes:
>> err = SndNewChannel(myChanPtr, sampledSynth, initMono, NULL);
>> if (!err) {
>>     err = SndPlay(myChanPtr, soundHandle1, FALSE);
>>     err = SndPlay(myChanPtr, soundHandle2, FALSE);
>> }

A minor point that I missed on first reading of the Sound Manager
chapter: the first parameter is a VARIABLE sound channel pointer; i.e.
the calling definition of SndNewChannel goes like:

	function SndNewChannel (VAR: chanPtr; ...)

In assembly language this requires extra care.  You must be sure that you:
a) set your chanPtr to NULL or to the pointer of your own created
pointer-block (using _NewPtr, size 1060 bytes); b) pass the ADDRESS of your
chanPtr to _SndNewChannel, NOT the pointer itself.

So it goes like this. . .  (with the appropriate push/pop macros)

	clr.l	myChanPtr(A5)	;if you're lazy; otherwise make your own
	push.w	#0		;space for the function result
	pea	myChanPtr(A5)	;NOT push.l myChanPtr(A5)!
	push.w	#0		;let SndPlay link a synthesizer typically
	push.l	#0		;(is this a longint? my docs aren't handy)
	pea	MyCallBack	;you definitely want this if you're going
				; to be playing asynchronously
	_SndNewChannel
	pop.w	D0		;error, if any
	...			;and on and on

MyCallBack	; This routine will execute in response to a callBack
		; command, which you pass to your channel with _SndDoCommand 
		; after you're finished with the channel.  This routine
		; should set a flag somewhere indicating the channel
		; is to be killed with _SndDisposeChannel as soon as is
		; convenient, but this routine should NOT do the disposing
		; itself, since it is not allowed to use the Memory Manager.

I realize the original poster was using Pascal, not assembly language, but
I hope this can help anyway.

>Also, you can't (in general) play 2 snd resources with the same channel.  
>When you play a resource, the synthesizer required by the resource is 
>linked to the channel.  If you link a syntehsizer more than once, you will 
>(at best) not get any sound, and will probably crash.

Precisely, although I have never understood why the Sound Manager works
in this way.  Why can't SndPlay check to see if a particular
synthesizer has already been linked to this channel, and if so, don't try
relinking?  SndPlay could be much more robust, it seems to me, but
then again I wouldn't want to have to write it. . .

----------------------------------------------------------------------
"May the forces of evil become confused on the way to your house."
                                                      -- George Carlin
Bemusedly,                   | DISCLAIMER:
  Colin Klipsch              |   This text is actually a horrendously
  UVa Astronomy Department   |   garbled excerpt from _Mating_Rituals_
  Charlottesville, Virginia  |   of_West_African_Ostriches_, Vol IV,
  cak3g@virginia.edu         |   by Davis & Griffin, 1913, p. 137
____________________________/ \_______________________________________