From alsa-devel-owner@alsa.jcu.cz  Mon Jan 25 16:53:37 1999
Received: from ife.ee.ethz.ch (ife-fast.ee.ethz.ch [129.132.24.193])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id QAA10290
	for <alsa-devel@alsa.jcu.cz>; Mon, 25 Jan 1999 16:51:36 +0100
Received: from ife.ee.ethz.ch (eldrich.ee.ethz.ch [129.132.24.203])
	by ife.ee.ethz.ch (8.8.5/8.8.5) with ESMTP id MAA01440
	for <alsa-devel@alsa.jcu.cz>; Mon, 25 Jan 1999 12:34:13 +0100 (MET)
Message-ID: <36AC56B4.79EF0900@ife.ee.ethz.ch>
Date: Mon, 25 Jan 1999 12:34:12 +0100
From: Thomas Sailer <sailer@ife.ee.ethz.ch>
MIME-Version: 1.0
To: alsa-devel@alsa.jcu.cz
Subject: Re: hi-res pcm sound support/IEEE floats
References: <01BE4713.64D3B7A0@muse>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

"Richard W.E. Furse" wrote:

> To summarise, using floats allows one to set the volume level of a signal
> chain where one wants (normally at the end) rather than having carefully to
> balance every step along the way to prevent signal damage that can be
> difficult to locate. To me this seems a very practical consideration.

The issue is no float in kernel space, and certainly not in an interrupt
handler. It's not a big issue for a user mode library, although I expect
that you should then add integer replacement algorithms for targets that
have very fast integer arithmetic but no hardware floating point,
such as StrongARM/Netwinder.

Tom

