Apparently-To: john.smith@gravis.com


GUS Programmer's Digest     Tue, 5 Oct 93   007 MDT      Volume 5: Issue   4  

Today's Topics:
                      More on recording pitfalls
                             Timer stuff

Standard Info:
	- Meta-info about the GUS can be found at the end of the Digest.
	- Before you ask a question, please READ THE FAQ.

----------------------------------------------------------------------

Date: Mon, 04 Oct 1993 18:27:48 -0400
From: davidm@marcam.com (David MacMahon)
Subject: More on recording pitfalls
Message-ID: <9310042228.AA02927@ottawa.marcam.com>

>In a previous digest, Tom_Klok@mindlink.bc.ca (Tom Klok) wrote:
[Interesting speculations deleted]
>Also, I find your measurements of time between DMA requests to be very
>interesting.  I use an 8-bit DMA channel myself.  So if you're using a
>16-bit channel, recording with 8-bit sampling, the GUS gives you two
>bytes at a time at half the rate?  In that case, using an 8-bit
>channel might reduce the problem (depending on the sampling rate,
>'natch).  Hmm... probably not.  Worth a try though.

I have done some more tests involving the DMA request timing and interrupt 
latencies.  The following timing "ascii-diagram" shows some of the times I 
measured.  All of my tests were done in mono mode on a 16-bit DMA channel.  
I have a 386DX-25.

     |<-2*Ts->|<-Ti+Ta+Ts->|<-2*Ts->|        DMA
     |        |            |        |      Requests
_..._|________|____________|________|_..._  (DRQ)
               _
              | |                          Interrupt
              | |                           Request
_...__________| |_____________________..._   (IRQ)

Where:  Ts = Sample Time (at programmed sampling frequency)
        Ti = Interrupt Latency Time
        Ta = Acquisition time of first sample

Each test that I ran had a different (programmed) sampling frequency.  I 
measured 2*Ts and Ti+Ta+Ts.  I don't have the exact numbers with me here at 
work, but here is what I concluded from examining the measurements:

1) The GUS does not sample at frequencies higher that 44100 Hz.  Even when 
programmed for higher frequencies, 2*Ts stayed at ~45 uS.

2) Ti+Ta = (Ti+Ta+Ts) - ((2*Ts)/2) = ~97 uS.  This was true for all the 
sampling frequencies I tried.

My "Record Handler" for these tests called UltraStartRecord.  I tried a 
version of my test that used "auto-init" mode and (not surprisingly) 
Ti+Ta+Ts was slightly reduced.  I didn't take measurements using that 
version because any program I've written that uses auto-init locks up my 
computer the second time I try to run it.  (I think because the PC's DMA 
hardware doesn't get shut down properly by UltraClose, but that's just a guess).

>I like your quick&dirty approach of fine-tuning the playback rate to
>account for the timing problems with ADC, Dave.  I also agree that
>larger buffers should minimize the problem.  Might let you run higher
>sample rates, too.

I implemented a larger buffer over the weekend and it definitely reduced the 
problem (but introduced a few new ones I have to fix).  I have been thinking 
about the q&d approach to fine tuning the playback rate and have begun to 
develop doubts about it's practicality.  With large buffers (32000), the 
actual difference (without integer math errors) between programmed sample 
rate and average sample rate is quite small (less than 5 Hz at 44100 Hz 
sampling frequency).  As far as running at higher sample rates, the samples 
sound fine when sampling at 44100 Hz, but I get a little click everytime the 
record buffer wraps.  I assume this is due to my 97 uS Ti+Ta (about 4 
samples that I lose every buffer wrap).

>But I also wonder... is there something we can to do to the GUS at the
>register level to let the GUS solve this problem for us?  If not, is
>there any chance that Forte will correct the GF1 for the next ASIC
>revision?  Or is the clocking problem not on the GF1, but on some
>external hardware?  In the PALs?  Will the 16-bit daughter board fix
>this?  Will the GUS Max have this problem?

Good questions!!! One way of working around this problem would be to attempt 
to measure Ti+Ta using the GUS itself.  It would work this way:

1) Program a ramp into the GUS' DRAM with each sample being one greater or 
less than the previous sample.

2) Play the sample at 44100 Hz.

3) Record at 44100 Hz.  Since the output is fed back into the input, you 
will be sampling the ramp that the gus is generating.

4) Measure how many sample are duplicated or missed.  Duplicated samples 
imply that Ti+Ta is less than Ts.  Missed samples imply that Ti+Ta is 
greater than Ts.  No duplicated or missed samples implies that Ti+Ta = Ts.

5) Using 44100 as a playback and record frequency, you would be able to 
calculate Ti+Ta to within 22.5 uS.  Using additional playback and record 
frequencies, you may be able to calculate Ti+Ta with even more accuracy.

6) Once you know Ti+Ta, use 1/(Ti+Ta) as the recording frequency.

Not ideal, but it might work.

>Gravis/Forte technical support, talk to us!  We're busy drumming up
>software support for your products.  The least you could do is help
>us out.

Ditto!  I wonder if they give game developers the same level of support they 
give to programmers over internet/Gravis nodes/sdk-digest.  That would 
explain why native GUS support is taking so long to appear in games.  I know 
they say "you get what you pay for", but do game developers pay for support 
or SDK's?  I hope not, that would be another reason native GUS support is 
taking so long.  Game developers probably get free hardware, SDK's, AND 
support.  Do Gravis/Forte have a developer program?  If so, what does it 
take to get on it (besides being a million dollar software company)?  Sorry 
to flame so badly here, but lately it seems that Gravis/Forte is *getting* 
alot more support from the internet community than they are *giving*.

>Oh!  One last idea.  Are you resetting the adsr (sample rate register)
>every time you restart on the next buffer?  In the SDK,
>UltraSetRecordFreqency().

No, I just call UltraStartRecord().

Dave

David MacMahon
Systems Administrator
davidm@marcam.com  <---New address, use this one
davidm@opl.com     <---Old address, don't use this one

------------------------------

Date: Mon, 4 Oct 93 06:33:32 PDT
From: deraud@power.amasd.anatcp.rockwell.com (Robert Lee DeRaud)
Subject: Timer stuff
Message-ID: <9310041333.AA24012@power.amasd.anatcp.rockwell.com>

>From: Tom_Klok@mindlink.bc.ca (Tom Klok)
>Subject: Re: How to avoid a recording pitfall (long ramblings)
>Subject: Re: How to avoid a recording pitfall (long ramblings)

