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)
