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)