From alsa-devel-owner@alsa.jcu.cz  Thu Jan 21 10:14:28 1999
Received: from entry.jcu.cz (IDENT:perex@entry.jcu.cz [160.217.1.111])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id KAA06936;
	Thu, 21 Jan 1999 10:14:13 +0100
Date: Thu, 21 Jan 1999 10:14:13 +0100 (CET)
From: Jaroslav Kysela <perex@jcu.cz>
To: "Richard W.E. Furse" <richard@muse.demon.co.uk>
cc: "'alsa-devel@alsa.jcu.cz'" <alsa-devel@alsa.jcu.cz>
Subject: RE: hi-res pcm sound support/IEEE floats
In-Reply-To: <01BE44CC.41B12C60@MUSE           >
Message-ID: <Pine.LNX.3.96.990121100624.28951C-100000@entry.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Wed, 20 Jan 1999, Richard W.E. Furse wrote:

> 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...

OK. Your arguments seems good, but the ALSA driver need covers all formats
which is expected by hardware. This doesn't have something with human
hearing, current recording/playback hardware limits etc... 

If a DSP for example expects data in 24-bit format (three bytes), why
a conversion from float -> 24-bit should be done in the driver?

OK. We can speak how will things work inside alsa-lib. Here maybe all
samples processed using float format and they should be converted to right
(hardware) format finally for the driver.

If you did look to my CVS changes I added 24-bit, 32-bit and float formats
to kernel side API as well..

							Jaroslav

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


