Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utcsrgv.UUCP Path: utzoo!utcsrgv!info-mac From: info-mac@utcsrgv.UUCP (info-mac) Newsgroups: ont.micro.mac Subject: Re: StartSound Message-ID: <4640@utcsrgv.UUCP> Date: Tue, 26-Jun-84 01:45:09 EDT Article-I.D.: utcsrgv.4640 Posted: Tue Jun 26 01:45:09 1984 Date-Received: Tue, 26-Jun-84 07:26:55 EDT Sender: peterr@utcsrgv.UUCP Organization: CSRI, University of Toronto Lines: 43 Date: Mon, 25 Jun 84 12:37:43 pdt From: Joseph I. PallasSubject: Re: StartSound To: croft@safe Cc: info-mac@sumex, sumacc@sumex From: Joseph I. Pallas Subject: StartSound To: croft@safe The assembly implementation of StartSound (both the Apple version and yours) has the ASYNC flag commented out. The effect of this seems to be that calls to StartSound do not return until the specified duration has passed. From: Bill Croft Subject: Re: StartSound Since there is only one buffer declared in the StartSound assembly helper, Apple probably wanted to reduce confusion and made the Write call synchronous. Otherwise they probably would have had to have a "TestSoundDone" routine and/or a "WaitSoundDone", etc. If you want to do ASYNC IO, then setup your own ParamBlocks and use the PBWrite call directly. There is probably an example of this in the SoundLab sample program. Alas, the SoundLab program is the question, not the answer. As an exercise, I transliterated SoundLab into C. The result works fine (well, almost), except that SoundLab calls StartSound and expects it to work asynchronously. SoundLab, in fact, does implement a sort of WaitSoundDone (very kludgily) by setting the duration to 1 and doing a delay loop. There's no question that the author of SoundLab believed StartSound was asynchronous. I'm willing to believe that someone decided to change that after SoundLab was written, given that the last date in its code is Jan. 1983; I just wondered whether there was any explanation for the change. joe