-----Original Message-----
From: Ed Hall 
To: Csound 
Date: Sunday, June 06, 1999 5:37 PM
Subject: Re: Higher numerical precission in Csound


>Michael Gogins wrote:
>> It is simply not true that Csound's internal precision equals or exceeds
>> that of professional audio gear. This may be true of some
semi-professional
>> gear, but it is not at all true of really high-end gear.
>
>Great!  So if you believe that 24-bit, 96Ks/s audio is essential and that
>every LSB is sacred, compile Csound with doubles, set sr=96000 and
kr=96000,
>output in floats or 32-bit ints, and be happy.  But why force this on the
>rest of us?


By asking for a compilation flag, I am not forcing anything on anybody. I am
asking that I and others like me be given the ability to make sounds at
least as precisely as pro gear can. Others will remain free to sacrifice
sound quality, perhaps a degree of sound quality that they are not using,
for working speed.

>I can easily see why audio gear using fixed-point computation would need
>at least 48-bit internal data to avoid overload.  (16-bit level X 24-bit
>sample is 40 bits; summing 64 channels of these would need 8 more bits
>of overhead; scale only on output.)  Floating point has some real
>advantages--a 32-bit float has 254 bits of dynamic range.  And given how
>much DSP power a few dollars buys these days, if the chip your mixer is
>built on supports 64-bit floating point, why not use it?  In a mixing
application, you have cycles to burn.  It looks good on the spec sheet,
>anyway.  But is it audibly better than 32-bit floating point?  IMHO, no.

For Studer, at any rate, the reason for more bits is not to avoid overload -
it's to avoid round-off errors (documentation for 950 mixer).

Some of the pro grear chips are floating point, some are fixed point; some
are in-house custom chips, some are Motorola, TI, or ADI.

>The 96dB dynamic range of 16-bit samples is arguably
>too small, but that's different than saying that 16-bit resolution is too
>small.  There is much less evidence of the latter, and the arguments
>I've heard for adding more than a bit or two of resolution have amounted
>to hand-waving, at best.

I don't think the pro audio business is basing its investment and
engineering decisions on hand-waving. 24 bits at 96 KHz is the emerging pro
standard. It is also the emerging audiophile digital audio standard.


>> Assume
>> that the digital audio samples coming into a system are 32 bits. Only a
few
>> arithmetic operations are required to introduce audible noise and
blurring
>> into the signal.
>
>Where in the (real) world are you going to get 32-bit samples?  Even pro
>A/D's only give you 20 bits or so above noise floor (120dB s/n ratio).


I am hoping to get 32 bit samples that mean something out of Csound. As a
musician, I look forward to being able to compute sounds that even the best
pro gear can't supply. And if my suggestion were followed, I would be able
to do it.

>> If, however, 64 or 80 bit samples are used, dozens of
>> operations can be performed without the noise floor cutting into the 32
bits
>> of the input signal.
>
>That's a 192dB noise floor you're talking about, there.
>
>> As a result, there will be no audible degradation of
>> the signal by round-off errors. Even if only 24 bits of precision are
coming
>> into the system, it will only take a dozen or so operations to raise the
>> noise floor.
>
>Well, actually, only one, since 32-bit floats have 24-bit mantissas.  But
>24 bits represents a 144dB noise floor.  Error estimation for floating-
>point calculation is notoriously difficult (dissertations are written on
>it), but in the cases of scaling (multiplication) and mixing (addition),
>we gain about 1/2 LSB of noise for each operation.  Thus we've lost a bit
>less than 6 bits (log2 (100 * 1/2)) after 100 operations.  Our noise floor
>is now around 110dB--for any musical purpose, still inaudible; it's way
below
>the 96dB maximum of a CD (a figure rarely achieved in practice).

It is well above the audible maximum of a 24 x 96 audiophile DVD.

>> If Csound were to follow standard professional audio engineering
practice,
>> it would support its 32 bit inputs and outputs with 64 or 80 bit internal
>> samples.
>
>"Support," yes.  Mandate, no.


Fine - all I need is support.

Erik Spjut wrote
>
>I would personally like to see the default for Csound to be doubles, so
>that beginners (and I) have less rope upon which to hang themselves.

don't understand any of this thread but less rope sounds good unless i'm
trying to climb out my apartment window (the fire trucks were across the
street again today -i don't know why the phone company building is always
on fire.)

>Perhaps we could take a poll

yes

>see what fraction of the user base depends on realtime

if this is what it comes down to: no realtime here. doubles please.

don't want to step on other users though. is a realtime version of csound
otherwise available on all platforms? (i would think many of the realtimers
would already be using the versions optimized for realtime and therefore
have no reason to object to doubles)

tolve

>If it's less than half then the default would be doubles, and
>the realtime people could be directed to the most excellent RTsound. If
>it's more than half, then floats it is, and perhaps some gracious person
>could help us poor souls who need or prefer doubles to get a decent
>compiled version.
>
>----------------------------------------------------------------
>Prof. R. Erik Spjut (spyoot rhymes with cute)
>Engineering Department, Harvey Mudd College, Claremont, CA 91711
>erik_spjut@hmc.edu   Ph. (909) 607-3890  Fax (909) 621-8967

>>The 96dB dynamic range of 16-bit samples is arguably
>>too small, but that's different than saying that 16-bit resolution is too
>>small.  There is much less evidence of the latter, and the arguments
>>I've heard for adding more than a bit or two of resolution have amounted
>>to hand-waving, at best.
>
>I don't think the pro audio business is basing its investment and
>engineering decisions on hand-waving. 

why not ? most other business operate on much the same basis, at least
part of the time. remember: the role of the pro audio business is to
make money; they make money by making people happy enough to want to
spend money on their products; they make people happy by convincing
them that their products are better than other possibilities. given
the complete lack of double blind testing by most people, this is
often done with hand-waving and pseudo-science babble at its best.
i'm not criticizing the excellent people who work in the pro audio
field, but they are part of an endeavour whose role is to make money,
not just to do the best thing. they may conceive of their role as
being whole technical, but they are part of a very complex process
(one that is well documented for the instrument side of things in a
book called "Making Music - Consuming Technology", I forget the author).
				       
				       24 bits at 96 KHz is the emerging pro
>standard. It is also the emerging audiophile digital audio standard.

actually, the "emerging" audiophile digital audio standard is 192KHz,
but not without a lot of disagreements over whether this is actually
necessary. Analog Devices Inc., for example, will soon have a DSP that
can handle this sampling rate, but it's designer thought it was a
mistake :)

I've been doing scientific computing (scientific and engineering models of
physical phenomena) for (altogether too) many years. I've reached the point
where the ONLY time I use single-precision floats is to interface with
someone else's code (like when running Csound). In my mind, the principal
reason for using double-precision is to insulate mere mortals from the
concerns of finite-precision numerical analysis. When you get that formula
from the math book (or friendly mathematician), you don't want to have to
analyze roundoff error and determine the best order of evaluation or
alternate forms. You just want to plug it in and use it. Single-precision
won't let you. Double-precision usually does.

When memory was tight, and processor speed slow, we all had to use single
precision, or better yet integers. You can work miracles and wring every
last bit out of a data type if you're willing to analyze roundoff and
truncation, pre scale all of your multiplicands, and precalculate all of
your filter peaks. In these days of a 300 MHz, 64 Mb, $400 machine, why
bother?

Many of us have run into the phasor-increment limit (on long notes, first
the frequency wavers, and then the note stops altogether). Doubles remove
the phasor-increment limit for notes less than a century long. I know there
are tricks to get around it, but why bother?

Recursive or IIR filters (including lpreson) run into stability problems
very easily. Doubles help a lot. I know there are workarounds (such as
ganged 2nd order sections) but why bother?

When I converted my Music11 orc's and sco's to Csound, I ran into a lot of
float problems (Music11 used doubles principally). I fixed them, but I had
to ask myself, why bother?

I am not advocating poor programming practice, but I am advocating getting
the job done with the least effort on my part. For most modern
architectures, the performance difference between floats and doubles is
around 5%. Which is faster, is not always clear. Realtime performance can
take a hit from the cache limit for doubles instead of singles. Long delay
lines can also be only half as long with doubles.

I would personally like to see the default for Csound to be doubles, so
that beginners (and I) have less rope upon which to hang themselves.
However, I don't know about the user base. Perhaps we could take a poll and
see what fraction of the user base depends on realtime and/or 5 minute
delay lines. If it's less than half then the default would be doubles, and
the realtime people could be directed to the most excellent RTsound. If
it's more than half, then floats it is, and perhaps some gracious person
could help us poor souls who need or prefer doubles to get a decent
compiled version.

----------------------------------------------------------------
Prof. R. Erik Spjut (spyoot rhymes with cute)
Engineering Department, Harvey Mudd College, Claremont, CA 91711
erik_spjut@hmc.edu   Ph. (909) 607-3890  Fax (909) 621-8967

	How about singles for ftables and doubles for internal
calcualtions. That way, you get the benifit of the higher precision where
it counts, and you don't overflow your cache ram by doubling the size of
ftables.
	I use both real-time and batch rendering about 50/50...
Cheers,
Mark Vigorito
mtv@u.arizona.edu