From mailserv@dsd.es.com Tue Aug 31 01:17:30 1993
Precedence: Bulk
Date: Tue, 31 Aug 93   :07 MDT
From: gus-sdk-request%itchy@dsd.es.com (GUS Programmer's Server)
Reply-To: gus-sdk%itchy@dsd.es.com (GUS Programmer's Digest)
Subject: GUS Programmer's Digest V3 #11

GUS Programmer's Digest     Tue, 31 Aug 93       Volume 3: Issue  11  

Today's Topics:
                             GUS SDK 2.01
               Simultaneous recording/playback works!!!

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, 30 Aug 1993 17:30:07 +0930 (CST)
From: Gavin <SCARMAN@hfrd.dsto.gov.au>
Subject: GUS SDK 2.01
Message-ID: <930830173007.11643@hfrd.dsto.gov.au>

I've asked this before but got no reply, so in desperation I'm asking again...

I have Borland C++ 3.1 and it's installed to the default directories. I have the 
GUS SDK 2.01 and it's also installed to the default dirs. I have created dirs 
largeb,tinyb, etc. When I run Make I get heaps of errors about undeclared 
functions and other stuff that scrolls past before I can read it. Obviously 
something is not set up right. What is it I need to do to get example.c to 
compile and link? ANY hints would be appreciated.
Gavin.

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

Date: Mon, 30 Aug 1993 15:33:51 -0400
From: davidm@opl.com (David MacMahon)
Subject: Simultaneous recording/playback works!!!
Message-ID: <9308301933.AA19125@ottawa.opl.com>

I have (finally) successfully managed to get my GUS to record data and 
playback those same data after a delay.  The delay can be so short that you 
can't notice it, or it can be as long as the GUS' memory/sample rate will 
accommodate.  What follows are several things I discovered while trying to 
get this done that may help others who are endeavouring to do the same sort 
of thing.  If you would like to try this program, please e-mail me.  If 
there is enough interest in my program, I will upload the executeable to epas.

DISCLAIMER:  Right now the program is in very rudimentary form, is not 
incredibly user friendly, and has no documentation (yet).  For these reasons 
it is not very useful, but it does demonstrate (quite well) that such a feat 
is well within the realm of the GUS and the low level SDK.  (These reasons 
are also why I will only upload the executable and not the source.)

1. You MUST use different DMA channels for recording and playback.  This is 
obvious, but I felt I should state the obvious.  I have the recording DMA on 
a lower (16-bit) DMA channel (higher priority) than the playback (16-bit) 
DMA, but I haven't played around with it to see if that really mattters.

2. Do NOT use EMM386.EXE.  I had this in my configuration and everything 
worked fine (SBOS, MEGAEM, AIL, native demos, etc.), but when I use EMM386 
with my program, the sound is horrendous.  I think it is missing samples 
because the DMA requests are being virtualized (i.e. slowed down).  Since I 
don't have 386Max or QEMM, I couldn't try those.

3. I tried using two different schemes to get the continuous 
recording/playback to work.  Both involved double-buffering.  Theoretically, 
both should work, but after I got one to work, I did not try to get the 
other one to work (because no one has answered my question about auto-init 
DMA :-( ).  Scheme 1 (which I did get to work) uses the Record Handler (no 
auto-init) at the end of each buffer to control the downloading of data to 
the GUS and ping-ponging of the buffers. Scheme 2 (which I did not get to 
work) uses a Timer Hanlder to download the first half of the buffer (buffer 
A) and the Record Handler (with auto-init) to download the second half of 
the buffer (buffer B).  On my 25MHz 386DX, I am able to use a sample rate of 
11025 Hz without losing any samples (that I can detect).  The only other 
rates I have tried are 22050 Hz and 44100 Hz, but I lose samples at both of 
those rates.

4. The playback rate and record rate are not always identical even if you 
ask for them to be identical.  This one really threw me for a while.  If I 
set it up for a noticeable delay time (1 sec), it would start out fine, but 
then the voice would creep up (IOW, the delay would shrink) and pass the 
point where I was writing new data into the GUS' memory.  I solved this by 
putting an UltraSetVoice call in the Record Handler to "correct" the 
position of the voice on every Record Handler call.  I know this "voice 
creep" happens at 11025 Hz which is one of the 256 discrete frequencies at 
which the GUS can sample.

5. This one bothers me because it seems to be a hardware limitation of the 
analog portion of the GUS itself.  In "Advanced Gravis Tech Note #20" which 
John Smith submitted to "Ultrasound Daily Digest V5 #18", it says...

>There is NO way to disable the Mic/Line in from being passed to the
>line out. Hence, you can record and playback at the same time but keep
>in mine [sic] what you are trying to record and what you are trying to
>play through the UltraSound will be mixed by the time it is outputed.

This is true, however, my experiences with my program indicate that the 
output is also mixed in with the input!!!  My program is set up to play the 
delayed data once and only once, but the volume of the voice that is playing 
the delayed data affects how many times the data is "echoed".  If you set 
the volume too high, you end up with a positive feedback situation where the 
data gets repeated at louder and louder levels until it breaks up into 
oblivion.  This has (at least) two bad ramifications.  The first is that the 
idea mentioned in "Advanced Gravis Tech Note #20" (i.e. writing "a recording 
studio program which would record to disk and while it is recording have the 
UltraSound verbally tell the user how much disk space they have left.") 
would work, BUT the time remaining announcement would be recorded along with 
the real data that you want to record.  The second is that if you want to 
use several different delays of the same data to create a unique reverb 
effect, you are going to get multiples of each delay summed in as well which 
is probably not desireable.  Speaking of this technique, it's too bad that 
you can't have "negative" volume that would play an inverse of the data.

That's all I can think of for now.  If I think of anything else, I'll post 
it.  If anyone has any comments, questions, or answers (even though I didn't 
really ask any questions), I'd like to hear them.

Dave

David MacMahon
Systems Administrator
davidm@opl.com

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

End of GUS Programmer's Digest V3 #11
*************************************

To post to tomorrow's digest:               <gus-sdk%itchy@dsd.es.com>
To (un)subscribe or get help:       <gus-sdk-request%itchy@dsd.es.com>
To contact a human (last resort):     <gus-sdk-owner%itchy@dsd.es.com>

FTP sites:         archive.epas.utoronto.ca         pub/pc/ultrasound
                   wuarchive.wustl.edu       systems/msdos/ultrasound
Hints:
      - Get the FAQ from the FTP sites or the request server.
      - Mail to <gus-sdk-request%itchy@dsd.es.com> for info about
	other GUS related mailing lists (UNIX, OS/2, GUS-MIDI, etc.)


