Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!att!pacbell.com!ucsd!dog.ee.lbl.gov!nosc!crash!jcs
From: jcs@crash.cts.com (John Schultz)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: playing samples using audio h/w
Keywords: audio DMA
Message-ID: <8202@crash.cts.com>
Date: 26 Mar 91 06:40:23 GMT
References: <2325@m1.cs.man.ac.uk>
Organization: Crash TimeSharing, El Cajon, CA
Lines: 30

In <2325@m1.cs.man.ac.uk> snowdond@r2.cs.man.ac.uk (D.N.Snowdon (MSc PJ)) writes:


>  I'm having a problem playing sound samples by hitting the
>hardware directly. The problem is that I set up the registers
>for the channel I'm going to use and set audio DMA going
> using 
>   move.w #(DMAF_SETCLR!DMAF_MASTER!DMAF_AUD0),dmacon(a0)
>as per the h/w manual. The sound starts playing OK.
>  If I then stop the sound by turning its DMA off using
>  move.w #DMAF_AUD0,dmacon(a0) again as in the h/w manual, 
>the sound stops. If I then reload the registers and start
>DMA going the sound I get is the remains of the first sample
>(assuming I stopped it before it had finished playing
>completely). The h/w manual does say that if you stop and
>start DMA over a short period then this can happen but there
>is actually quite a long delay between turning off DMA for
>the first sample and turning it on for the second.
>  Can anyone shed any light on this?

  Yeah, there's a bug in the hardware.  The best way around it (so you
don't waste cpu cycles waiting) is to set PER to 1, then write directly
to DAT and wait for the interrupt. A better (and more elaborate) scheme
is to set up an interrupt handler that handles this special case.
When the interrupt occurs, stuff the new values into all the necessary
registers. Also, before writing to DAT, turn off audio DMA (This effects
when interrupts occur).


  John