From alsa-devel-owner@alsa.jcu.cz  Thu Jan 21 00:27:00 1999
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id AAA31744
	for <alsa-devel@alsa.jcu.cz>; Thu, 21 Jan 1999 00:26:29 +0100
Received: from [158.152.21.220] (helo=MUSE)
	by post.mail.demon.net with smtp (Exim 2.10 #2)
	id 10370v-0002Ad-00
	for alsa-devel@alsa.jcu.cz; Wed, 20 Jan 1999 23:26:21 +0000
Received: by MUSE            with Microsoft Mail
	id <01BE44CC.41B12C60@MUSE           >; Wed, 20 Jan 1999 23:26:07 -0000
Message-ID: <01BE44CC.41B12C60@MUSE           >
From: "Richard W.E. Furse" <richard@muse.demon.co.uk>
To: "'alsa-devel@alsa.jcu.cz'" <alsa-devel@alsa.jcu.cz>
Subject: RE: hi-res pcm sound support/IEEE floats
Date: Wed, 20 Jan 1999 23:25:04 -0000
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Hmmm. I'm going to ramble a bit and then argue to suggest that we should do 
8bit audio, 16bit audio and then go straight to IEEE 32bit floats. Bear 
with me. Oh, and I've been down the pub so I may make less sense than 
should be ideal. You already have the summary however...


ARGUMENT 1 (signal/noise, limits of human hearing, logarithmic/linear 
audio)

A) Much as I hate to throw a spanner in the works, I think the current 
discussion rather pointless and flawed. There is NO POINT in more than 
24bit linear audio on playback. Set up your perfect amp correctly so that 
playing a square wave at 1bit is just inaudible, i.e. "0dB" as the 
environmental sound people record it. Then play another square wave at 
24bits over the same amp. This will give you about 140dB. This is into the 
immediate serious hearing damage range, louder than standing near a jet 
taking off, way higher than the loudest rock concert you've ever been to. 
By this same scale, 16bit audio gives a lot of dynamic range. There's an 
argument for a little more than 16bits on playback systems, particularly 
for music with a large dynamic range. But not a very strong one for 
ordinary applications.

In contrast, signal-to-noise ratios and dB range for 
recording/production/mastering purposes is an entirely different ballgame, 
and the reason is headroom, or "clipping" as the digital world faces it. 
Clipping is evil and should be avoided at almost all costs. To avoid 
clipping I might record at -24dB. But then all of a sudden most of the take 
uses only 12bits, and when you multiply the amplitude by 16 to present it 
on a 16bit (96dB) system, the noise floor is clearly audible. However if 
the original recording was taken accurately at 20/24 bit, this would not 
have been an issue. But this is because there is a full 16bit signal 'a bit 
further down', i.e. there's a signal with 16bits of detail that is 
amplified a few bits out of place and can be easily got to.

B) IEEE floats, last time I looked, use a 24bit signed mantissa, (i.e. a 
linear signal component) and an 8bit exponent. The 8bit exponent indicates 
a power of two for the signal, giving an overall loudness. i.e. a sample 
has form

	+<------mantissa------->       +<-exp->
	110001101011010110110101 * 10^(01101001)

in base 2.

This is perfect for audio, as at any reasonably consistent amplitude (i.e. 
accessibly via the exponent, or within 2^255 i.e. 1500dB) you have a full 
24bits of detail available, taking you from perceived silence to hearing 
damage.

C) Recording is generally electromagnetic. Computers produce lots of 
electromagnetic radiation. More than 24bits recorded within 3m of a PC? I 
think not.


ARGUMENT 2 (Manipulation (and more signal/noise))

Take a signal. Multiply it by 10000. Add it to another of similar 
amplitude. Divide it by 10000000. Mix it with another. Multiply it by 
another signal with amplitude 100000000. etc. This is the food and drink of 
serious computer music--people use the float because it has the capacity to 
deal with the loud and soft signal without clipping or disappearing into 
silence--the noise floor is derived from the worst noise floor of the two 
signals based on signal/noise rather than where they happen to fit in the 
particular 32bit scheme (or whatever) in use. Having some exponent bits 
makes all the difference.

All serious audio tools with which I've gone 'beneath the surface' have 
used 32bit IEEE floats internally. Having the input signal presented as 
32bit linear would require throwing away the last 8 bits anyway on a full 
amplitude signal before even starting, an expensive cast at best.

If you process using 32bit ints, sooner or later you clip or disappear into 
the noise floor. I know, I've tried it. Floats don't have this problem.


ARGUMENT 3 (The Done Thing)

Last time I looked at DSPs etc, they also used floats (IEEE floats) 
internally. I believe most of the Motorola chips do, the Intel FPUs and MMX 
chip certainly do, and every time I've gone near anything else of that ilk 
using words that small, IEEE floats have seemed to be the standard. I 
gather there has been a little more argument about double-precision floats, 
but not much. I venture a guess that Event and other companies are using 
precisely this. I think it enormously unlikely they have even considered 
using 32bit linear integers for audio.


ARGUMENT 4 (It's easy)

If you've got a 16/20/24bit signal being written as raw data into memory, 
it's pretty easy to assemble floats from it.


ROUND UP (would be summary but there's new material)

16bit audio should remain the staple diet of Linux because most audio is 
playback audio and 16bits on a good amp gives 0dB to 96dB as silence to 
neighbour-disturbing loud. 96dB/16bits is good for playback.

8bit linear is useful for toy applications. 8bit logarithmic is actually 
better for many applications as it gives a much lower noise floor, but it 
induces odd audible distortions. These are noticeable as the absence of a 
noise floor means that the brain doesn't mask them out. Also, mixing 
signals is hard.

20/24bit audio is cool, and extremely useful for recording/production etc, 
but playback making full use of 24bits means you just damaged your 
audience's hearing. Do you want that on your conscience?

32bit (linear) audio is a waste of time. You'll never ever hear the detail 
anyway. If you've another 8bits to spend, wouldn't they be better spent on 
an exponent, leading to...

32bit float = 24bit(linear) + 8bit(exponent). Best of all worlds, and 
probably what the DSP on your sound card is using anyway.


RANT OVER

(for now)

Badly expressed I know, but the flavour and ideas should be there.


-- Richard


-----Original Message-----
From:	Jaroslav Kysela [SMTP:perex@jcu.cz]
Sent:	Wednesday, January 20, 1999 10:28 AM
To:	Elliot Lee
Cc:	alsa-devel@alsa.jcu.cz
Subject:	Re: hi-res pcm sound support

On Tue, 19 Jan 1999, Elliot Lee wrote:

> On Tue, 19 Jan 1999, Jaroslav Kysela wrote:
>
> > > Does the ALSA architecture have room for higher resolution (e.g. 
24-bit
> > > 96Khz) PCM sound recording and playback? The asound.h that I looked 
at
> > > only said anything about 8 and 16-bit sound.
> > >
> > > It would be really nice if someone with a professional audio 
background
> > > would ensure that ALSA has everything needed for pro sound 
production.
> >
> > It is possible enhance API for more than 16-bit resolution, but as I 
asked
> > before (without any answer yet): How are 16+-bit samples encoded to
> > stream? How bytesex is used (one or both)?
>
> The endianness that sound cards expect and samples use varies, but other
> than that it would seem that 24-bit numbers follow the same endianness
> rules as 16-bit numbers, you just need three bytes instead of two...?
>
> The .wav file standard (available at http://www.wotsit.org/) says:
>
> Because most CPU's read and write operations deal with 8-bit bytes, it 
was
> decided that a sample point should be rounded up to a size which is a
> multiple of 8 when stored in a WAVE. This makes the WAVE easier to read
> into memory. If your ADC produces a sample point from 1 to 8 bits wide, a
> sample point should be stored in a WAVE as an 8-bit byte (ie, unsigned
> char). If your ADC produces a sample point from 9 to 16 bits wide, a
> sample point should be stored in a WAVE as a 16-bit word (ie, signed
> short). If your ADC produces a sample point from 17 to 24 bits wide, a
> sample point should be stored in a WAVE as three bytes. If your ADC
> produces a sample point from 25 to 32 bits wide, a sample point should be
> stored in a WAVE as a 32-bit doubleword (ie, signed long). Etc.
>
> And since WAVE samples are stored little-endian, the 24-bit number would
> be stored as such.

OK, I added all four types for 24-bit format to header and source, too.

							Jaroslav

-----
Jaroslav Kysela <perex@jcu.cz>
Academic Computer Centre, University of South Bohemia
Branisovska 31, C. Budejovice, CZ-370 05 Czech Republic

------
To unsubscribe from <alsa-devel@alsa.jcu.cz> mailing list send message
'unsubscribe' in the body of message to <alsa-devel-request@alsa.jcu.cz>.
