Path: utzoo!attcan!uunet!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!hplabs!hpda!hpcupt1!hpindwa!krisl
From: krisl@hpindwa.HP.COM (Kris Livingston)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Simultaneously played digitized sounds
Message-ID: <36690003@hpindwa.HP.COM>
Date: 3 Jul 90 15:25:13 GMT
References: <1032@swan.ulowell.edu>
Organization: Hewlett-Packard, Cupertino CA
Lines: 45

>Here's what I did:
>I wrote a vertical retrace task that would take requests to start sound on
>one of 4 channels (with options for what to do when that channel is being
>used) and play it at 11 kHz until completion or interruption.  When it gets
>woken up by the VBL manager, it loads the sound buffer, does house keeping
>and requeues itself.  This worked like a charm --but for only 1 voice.  The
>problem came in handling multiplexing.  Whatever technique I tried failed
>miserably (ie, it played but with lots of unacceptable distortion).
>Bummer deal!  I tried averaging, I tried OR'ing I even tried scrubbing, but
>they all worked poorly.  I knew it wasn't a time problem because I tried each
>"channel" running with 3 other "null" channels, and it was clean (ie, it still
>did the math for multiplexeing, but something that would be a NO-OP to the
>data.

You're on the right track.  When your VBL task grabs a chunk of bytes from
your sound waveform, it should also grab bytes from 3 other waveforms and 
ADD THEM TOGETHER.  For example, if your current index into any given
waveform is i, then the byte you want to stuff into the sound hardware
buffer is wave1(i)+wave2(i)+wave3(i)+wave4(i).  The trick to avoid the
nasty distortion is to pre-divide the values in each of the waveforms by 4
(the number of voices being combined).  The advantage to this is that the
only processing your VBL task needs to do is addition.  The disadvantage is
that the volume (loudness) of the overall sound is reduced.  You could
experiment with dividing the waveform data by 2 (instead of 4) and then
check for overflow.  (If sum > 255 then sum = 255).  I know, it's crude,
but I've used it and it works--just don't plan on using the CPU for much
else while this is going on.  :-)

>The real bad news:  Even if this code DID work, it would probably only work on
>a Mac SE or earlier machine because of the strict hardware dependency (although
>it did make correct use of the correct sound buffer base address).  And it
>was written in inline assembly for the most part.

You're right.  Hardware dependency is a real concern here.  Apple has made
some hardware-specific patches to the system software so that programs
using this kind of approach might still work on newer Macs (I've tested
this stuff on a Mac IIx--works fine) but you can bet that when System 7
shows up, nothing will work except proper Sound Manager programs.

>Steve Hawley
>hawley@adobe.com
>-- 

Kris Livingston
krisl@hpindwa.hp.com