mks@cbmvax.commodore.com (Michael Sinz) (04/06/91)
> Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site cbmvax.commodore.com > Path: cbmvax!rutgers!ucsd!ames!sparkyfs.erg.sri.com!noose.ecn.purdue.edu!en.ecn.purdue.edu!bevis > From: bevis@en.ecn.purdue.edu (Jeff Bevis) > Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.audio > Subject: Audio state machine > Message-ID: <1991Mar31.195357.20689@en.ecn.purdue.edu> > Date: 31 Mar 91 19:53:57 GMT > Date-Received: 31 Mar 91 21:16:36 GMT > Followup-To: poster > Organization: Purdue University Engineering Computer Network > Lines: 64 > Keywords: nitpicking > Summary: it's flawed, imho > Xref: cbmvax comp.sys.amiga.programmer:2202 comp.sys.amiga.audio:513 > > A few days ago I posted a plea for help with my audio software. "Simple," > thought I, "the Amiga audio programming will be." Ho ho hooo! Was I ever > wrong. I was completely dumbfounded by the behavior of the interrupts. > Sometimes I'd get sound, other times not. Sometimes the right sound, other > times the previous sound again. Frequently the interrupts would hack off > the sound early. I was about to go bonkers. BUT, I re-discovered the > 'Audio State Diagram' on page 162 of the Hardware Manual. Lord, how could > I have overlooked this before?? (blinded by my confusion, I suppose.) > > Well, how many of you have really taken a *good* look at that page? Until > now, not me. But it seems, upon careful inspection, that the machine is > flawed. That's because there's no *easy* way to force the machine into > a known state rapidly. Ah, but there is. In the hardware manual (Blue edition) there is a note about this. It notes this problem (which you describe below) and also notes a simple, and always supported solution. When I reworked (not redid) audio.device for 2.0, I implemented into audio device these methods. (The old audio.device was not correctly doing it.) The fix is simple. When you want to get out of a sound, you will want to set the volume register to 0 and the period register to 1. Since these are a register "pair" it can be done with one write operation from the CPU. Settings in the volume and the period register take effect within 1 colour clock (actually, it usually is much faster, but...) At this point the sample finishes. If you have DMA turned on, you will have to be able to deal with the interrupt that will happen. Normally, you turn DMA off. Since these registers are per-channel, you have full control of when you want to exit the state machine. > Ok, let's suppose you're doing DMA-driven audio (like me), and you were > initially in the 000 state (idle), and you set things in motion with > AUDxON. You'll soon end up in states 010/011, cycling back and forth > pumping out audio bytes. If you want to stop this, the only path out > of the loop requires the period counter to be finished decrementing, the > DMA must be turned off, and there must be an interrupt pending for the > audio channel (in intreq). Of these three conditions, only the second > (DMA turned off) can be controlled directly. To satisfy the first > (perfin, in the diagram) the period counter *must* count down completely > -- so, if you've chosen a period of, say, 3000 previously, then you'll > have to WAIT up to 3000/3579552 seconds (838 milliseconds!!) to get the > channel back... no way out. For higher periods, it gets still worse. > > What we need here is one new control bit for each channel... AUDxHLT - an > audio 'halt' bit. This bit should take the state machine from state 011 > to idle (000) by making the transition condition There is no need for this control method as it is already there. If you look at audio.device, it has a CMD_FINISH and CMD_FLUSH command both of which need to do a form of halt. The 2.04 audio.device does this correctly per the description above. [details of the HLT line removed] > Feel free to bombard me with criticism, additional ideas, etc... I don't want to bombard you. You have a valid point, but it has been addressed without the need to make a new chip and invalidate software. Also, the method described above give more control to the software as it can blow away individual DMA cycles or the whole chain. (BTW - It is also set to not "click" or "pop" That is why the volume is set to 0 too.) -- Michael Sinz Operating Systems Development Group Commodore-Amiga, Inc. /----------------------------------------------------------------------\ | /// Michael Sinz - Amiga Software Engineer | | /// Operating System Development Group | | /// BIX: msinz UUNET: rutgers!cbmvax!mks | |\\\/// | | \XX/ Quantum Physics: The Dreams that Stuff is made of. | \----------------------------------------------------------------------/