From mailserv@gaia.ucs.orst.edu Sat Jun 25 21:00:40 1994
Precedence: Bulk
Date: Fri Jun 24 14:08:10 PDT 1994
From: gus-sdk-request@gaia.ucs.orst.edu (GUS Programmer's Server)
Reply-To: gus-sdk@gaia.ucs.orst.edu (GUS Programmer's Digest)
Subject: GUS Programmer's Digest V12 #7

GUS Programmer's Digest     Fri, 24 Jun 94 14:08 PST     Volume 12: Issue   7 

Today's Topics:
                              3D patches
                    GUS Programmer's Digest V12 #6
                     Signed vs. Unsigned Samples

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: Fri, 24 Jun 1994 11:18:07 +0100
From: P.VanHorssen@hol0606.wins.icl.co.uk
Subject: 3D patches

Hi, I am trying to use the SDK to workout 3D patches. I can use
some hints and tips of somebody who already achieved this.
Any bidders?

Greetings, 
Pieter van Horssen

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

Date: Thu, 23 Jun 1994 20:02:29 -0400 (EDT)
From: mikebat@netcom.com (Mike Batchelor)
Subject: Re: GUS Programmer's Digest V12 #6

Not the GUS Programmer's Server once wrote...
$  
$  ------------------------------
$  
$  Date: Thu, 23 Jun 94 02:11:43 -0600
$  From: cornel.huth@lchance.sat.tx.us
$  Subject: GUS MAX SDK AVAILABIL
$  
$  3 - And is the super-flux jumper going to be documented, or does this mode
$  remain undocumented?

Super-flux jumper?  

-- 
Mike Batchelor      | UseLinuxUseLinuxUseLinuxUseLinuxUseLinuxUseLinuxUseLinux
mikebat@netcom.com  | xuniLesUxuniLesUxuniLesUxuniLesUxuniLesUxuniLesUxuniLesU
 -----------------------------------------------------------------------------
It is said that Dreams are real while they last.
Can we say more of Life?

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

Date: Thu, 23 Jun 1994 16:09:36 -0700 (PDT)
From: David.Roberts@amd.com (Dave Roberts)
Subject: Signed vs. Unsigned Samples

I was just sitting down the other day and thinking about mixing
samples and the GUS and ultraclicks and so forth ('cause I do that
sort of thing sometimes).  Anyway, I came to the conclusion that
unsigned samples are probably bad and might be a source for many of
the GUS's ultraclicks.  Just so we have our terminology straight, an
unsigned 8-bit sample has it's zero-point, or silence point, at value
128.  Value 127 is below the zero point, and 129 is above it.  With a
signed 8-bit sample, 0 is the zero point.  255 is one less than the
zero point, and 1 is one above it.

Now, the following is predicated on an assumption about how the GUS
mixes samples internally.  The question is, does the GUS convert the
samples to signed values internally, or are they mixed as unsigned
values.  The following will explain the problem.

Consider two voices playing silence with signed samples (e.g., value
0).  To mix the voices, simply add them together and dump the result
to the DAC (note that I'll ignore volume, pan, etc., for now).  0 + 0
= 0.  In other words, two times silence is still silence.

Now, consider the unsigned case (e.g., value 128).  If you have two
voices, then these add to 128 + 128 = 256.  In other words, two times
silence is twice as deafening.

Now there are ways to handle the fact that we're at the 256-level, and
that's not the issue.  Some people divide by two to bring the value
back to 128.  Others just have a larger than 8-bit accumulator to
store the sum in.  In actuality, the correct method is to subtract 128
from the total.  Consider the signed case of two samples playing value
2.  Here you'd have 2 + 2 = 4, or 4 steps above silence.  If you have
130 + 130 (the unsigned case), you'd have a sum of 260.  If you divide
this by two, you get 130, or only two steps above silence, not four.
In effect, your dynamic range has be halved by the divide, as
expected.  You can get 4 steps above silence in the unsigned case by
subtracting 128.  For example 130 + 130 - 128 = 260 - 128 = 132, which
is four steps above silence.  For each voice you add above the first,
you simply add the samples and subtract 128 to correct the value.

Now, I don't think this is what the GUS does.  I think the GUS uses
unsigned samples all the way through and simply adds them up into a
large accumulator.  So, when playing the 130 + 130 case, the GUS
simply gets a result of 260 and sends that to the DAC with no further
processing (again, I'm ignoring volume, etc., for now).  I think many
ultraclicks are caused by this behavior.

For instance, consider two voices playing value 130, as above, and
another note starts to play.  Say the note just plays silence, not any
actual sounds.  So we start to mix this silence in: 130 + 130 + 128 =
388.  Even though we're mixing in just silence, the output value going
to the DAC jumped.  I think this is the cause of most ultraclicks that
occur when stopping and starting a voice.  Most of the time a stopped
voice is pointed to a true zero value, as the SDK recommends that it
should be.  So the GUS jumps from doing a (in the 14 voice case)

voice#
1     2     3     4   5   6   7   8   9   10  11  12  13  14
 -----------------------------------------------------------
130 + 130 + 0 +   0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0   = 260

to a

voice#
1     2     3     4   5   6   7   8   9   10  11  12  13  14
 -----------------------------------------------------------
130 + 130 + 128 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0   = 388

The SDK recommends using a fast volume ramp when starting or stopping
a voice and this is to try to reduce the immediate step from value 260
to 388 all in one shot.  The ramp might have the value change from 260
to 300 to 340 to 380 to 388.  In other words, smaller discrete jumps
to reduce the click.

If you were to use signed samples, you'd simply have a single case:

voice#
1     2     3     4   5   6   7   8   9   10  11  12  13  14
 -----------------------------------------------------------
2  +  2 +   0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 0   = 4

Adding in all the silence you want on any number of additional voices
doesn't affect the output value because 0 really equals the silence
value.

Now it seems that you could go a long way toward reducing clicks if
you'd point a stopped GUS voice at a 128 value.  In other words
the two-active-voice case would look like

voice#
1     2     3     4   5   6   7   8   9   10  11  12  13  14
 -----------------------------------------------------------
130 + 130 + 128 +128+128+128+128+128+128+128+128+128+128+128   = 1796

So the combined silence-value of fourteen possible voices is 14 * 128
= 1792.  As you can see, the 1796 value is four steps above the
combined silence value.

So, am I missing something, or is the SDK actually causing ultraclicks
by recommending that a stopped (but active) voice be pointed at a true
0 value?  Should we really be pointing our stopped (but active) voices
at 128 values?  Further, am I right that signed samples actually make
much less sense when mixing is involved (note that there is no problem
with a single channel playing without mixing -- signed or unsigned is
equivalent in this case)?  If the reason for using unsigned samples is
to make the DAC easier to build (for instance, it must be easier to
build a DAC where 255 is larger than 0, not the other way around, as
in the signed case) then the total mixed signed value could be
converted to unsigned right before it is sent to update the DAC.

Now, you get bonus points if you can tell me how volume fits into this
whole thing.  For instance, in an unsigned system, if silence is
playing at 1/2 volume, does that add a 64 to the accumulated output or
what?

Phat or Dave, did you guys come to any conclusions about this when you
were doing your research on ultraclicks and how to avoid them?  You
gave a lot of information about GUS interpolation idiosyncracies
causing clicks during looping but I don't remember any mention of
clicks at the start or end.

Just me sitting here, thinking too much... :-)

Dave Roberts
Advanced Micro Devices, Inc.
I/O and Network Products Division
david.roberts@amd.com

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

End of GUS Programmer's Digest V12 #7
*************************************

To post to tomorrow's digest:                    <gus-sdk@mail.orst.edu>
To (un)subscribe or get help:            <gus-sdk-request@mail.orst.edu>
To contact a human (last resort):          <gus-sdk-owner@mail.orst.edu>

FTP Sites              Archive                       Directories
---------              -------                       -----------
Main N.American Site:  archive.orst.edu              pub/packages/gravis
                       wuarchive.wustl.edu           systems/ibmpc/ultrasound
Main Asian Site:       nctuccca.edu.tw               PC/ultrasound
Submissions:           archive.epas.utoronto.ca      pub/pc/ultrasound/submit
Newly Validated Files: archive.epas.utoronto.ca      pub/pc/ultrasound
Mirrors:               garbo.uwasa.fi                mirror/ultrasound
 
MailServer For Archive Access: Email to <mail-server@nike.rz.uni-konstanz.de>

Hints:
      - Get the FAQ from the FTP sites or the request server.
      - Mail to <gus-sdk-request@mail.orst.edu> for info about other GUS
	related mailing lists (general use, musician's, etc.).


