Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!decwrl!labrea!polya!rokicki From: rokicki@polya.STANFORD.EDU (Tomas G. Rokicki) Newsgroups: comp.sys.amiga Subject: Re: Sampling at 29KHz (long) Message-ID: <2850@polya.STANFORD.EDU> Date: 18 May 88 23:24:16 GMT References: <2845@polya.STANFORD.EDU> <734@eos.UUCP> Reply-To: rokicki@polya.Stanford.EDU (Tomas G. Rokicki) Organization: Stanford University Lines: 81 > Obviously, one should not try to play frequencies higher than the Nyquist > frequency; this is what you so laboriously illustrate. Your examples are > not very realistic, however. Let's take a simple sine-wave synthesis > instead (not the most realistic scenario either, but so simple as to be > an example of what an audio driver *should* be able to handle). But if you try to play back a waveform that *includes* high frequencies by undersampling, those high frequencies come back and haunt you. That is the point I am trying to make. > Compute a 256-point sine wave and put it in memory (32-byte sine waves > don't cut it in my book - even a tin ear can hear the interpolation > noise in fixed, jagged steps that big). As chuck said, a square wave at 14KHz should be filtered to a very nice little sine wave; that is what the filter is for. A square wave at frequency f looks something like sin(ft+a_1) + 1/3 sin(3ft+a_2) + 1/5 sin(5ft+a_3) . . . where the a_i's are phase shifts. The filter should attenuate the third and fifth etc. harmonics almost entirely, leaving you with a very nice sine wave. > With a fixed sample-playback > increment and a maximum rate of 29 KHz, the highest frequency you can > generate is 29000/256 = 113 Hz! - just about TWO OCTAVES below A440(!) Correct, assuming you stick with that 256 sample table. > With this same sine wave and a variable (intergral.fractional) sampling > increment, one could generate a maximum frequency of 14 KHz! Yes, but because of the integral.fractional nature of your incrementing, you are guaranteed to introduce some amount of garbage into your sound; all your peaks won't peak at the same point, etc. Although this effect probably won't become really bothersome until you are up to about 1/8 of the maximum frequency or so. > My point is, it is the combination of a relatively low sampling rate > *and* a simple increment method that makes the sound driver so > inconvenient to use. Fix one or the other if you want a high quality > and flexible sound device (I'd pick the increment as the easier to fix, > though I don't appreciate the subtleties of the Amiga's DMA). But the sampling rate is variable; this is what makes it a win. I really don't understand what is so hard about having multiple tables; if you do octave tables, you need only twice the storage of the original table (1+1/2+1/4...~=2). > I enjoy playing with its synthesis capabilities, and > wouldn't mind if one waveform of say, 256 bytes, could be used over five > octaves - not a tall order. I used to be able to do *that* with a 6502. Ever feed the 6502-generated signal into a spectrum analyzer? > Your postscript tosses off a reference to *making* the other octaves of > sound - this is called interpolation, a process which has earned many Ph.D's > over the last ten years. Try interpolating 4 octaves from one sample *live* > sometime (can you say "Cray killer?") But it only needs be done once for each sample . . . even a full FFT, filter, and reverse FFT doesn't take long for a 256 byte sample. Not real time, true, but for synthesis? Faster than you can figure parameters for the sample. > > Any further comments? > > Yes. Why is it that articles that start out with "I really don't know > much about this but..." always turn out to be the longest ones? :-) Well, I'm trying to learn myself, so I presented what I think I understand to be the case, and I hope to be corrected where I am wrong. > Phil Stone (I still love the Amiga sound driver) -- /-- Tomas Rokicki /// Box 2081 Stanford, CA 94309 / o Radical Eye Software /// (415) 326-5312 \ / | . . . or I \\\/// Gig 'em, Aggies! (TAMU EE '85) V | won't get dressed \XX/ Bay area Amiga Developer's GroupE