Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!csd4.milw.wisc.edu!bionet!apple!well!farren
From: farren@well.UUCP (Mike Farren)
Newsgroups: comp.sys.amiga.tech
Subject: Audio quirks
Message-ID: <12293@well.UUCP>
Date: 21 Jun 89 08:15:03 GMT
Reply-To: farren@well.UUCP (Mike Farren)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 64


Well, having just fought my way through a three-week battle with the
audio.device, I thought I'd put a few notes out, for all of you folks
who might want to do real nice sounds, and lots of 'em...

I have just completed the conversion of the Macintosh game "Crystal Quest"
to the Amy.  CQ is noted for its interesting sampled sounds on the Mac,
and one of the primary goals of the conversion was to replicate those
sounds.  "No problem," I think, "I'll just whip up a quick audio IO
routine."  So, I did something that looks like this:

Init - allocate four channels, three ioa's per channel for bookkeeping
convenience.

Play - check channel with CMD_READ.  If busy, issue CMD_RESET (or, at
one point, CMD_FLUSH), Wait() for return.  Then, issue CMD_WRITE to
produce sound.

repeat as necessary (sometimes, many times per second as events occur).

The result: occasional crashes which had as their main symptom a total
lock of the machine, accompanied by either endlessly repeating CQ sounds,
or something which _sounded_ like the audio channel was "playing" some
system memory or other - you could hear the keyboard, mouse, and disk
accesses over the audio channels!

O.K., says I - this means that I can't use the audio.device routines.
I'll have to roll my own.  No problem - just stuff stuff into the
registers directly, and provide a new interrupt routine to service the
audio interrupt.

Well, there's a problem here, too - the documentation for the audio
hardware is sadly deficient.  They tell you that the hardware issues
an interrupt at the end of the audio block, which is great - that allows
you to shut the damn thing off to prevent infinite repeats.  What they
only mention in two spots in the Hardware manual, and in fine print at
that, is that that is not the only time the hardware issues an audio
interrupt.  It also issues the interrupt when the registers you've
stuffed data into are copied into the actual working registers in the
hardware, i.e., when you initially turn on audio DMA.  What's more,
there is no way that I could see to determine unequivocally WHICH of
the two circumstances caused the interrupt, from the point of view of
the interrupt routine.  No flags, no nothing.

Here's what I ended up with:

Play sound: turn off audio DMA.  Wait enough time to be SURE that the
channel is reset (I used MOVE #100,D0 - DBF d0,<here> - probably overkill).
Stuff values into registers, set a flag to 1, turn on DMA.

Audio Interrupt: check flag.  If 1, set the flag to 2, return.  If 2,
turn off audio DMA, wait enough time (again) to be sure channel is reset,
set flag to 0, return.

It would have been a lot handier if C/A had provided two things: first,
a flag to indicate which of the two states had caused the interrupt.
Second, a "hard reset" capability for the channel which would not
require waiting "approximately two sampling periods" to ensure the
actual resetting of the channel.  While it seems to work o.k., I hate
the idea of delay loops in an interrupt routine - it's not very polite,
you know?

-- 
Mike Farren 					 uucp: well!farren