Re: [linux-audio-dev] float a/d (was Linux support for IEEE1394 mLAN?)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] float a/d (was Linux support for IEEE1394 mLAN?)
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sun Sep 24 2000 - 16:45:54 EEST


On Sat, 23 Sep 2000, Tom Pincince wrote:

>
> I recently spoke with an audio old timer who owns a Studer 1 inch half
> track 30 ips open reel mastering deck. If analog tape resolution is
> proportional to tape surface area, then the resolution of his deck is
> 256x the resolution of consumer cassettes (1/8 inch quarter track 1 7/8
> ips). For him the switch to digital has been torture. One of the
> complaints of daw's is that the editing is done at the same resolution
> as the consumer playback format. You already see the challenge of
> maintaining precision at float 32 for a single process. Imagine
> processing one track with a compressor, two bands of parametric eq,
> panning, and a gain fader. That was 5 separate processes each
> contributing cumulatively to the truncating/rounding errors of the LSB.
> Now mix 64 channels that have each been similarly processed and how far
> beyond the LSB do you think the quantization noise has migrated? I feel
> that if the consumer format provides a resolution with quantization
> noise that is marginally beyond the threshold of audible perception,
> then the daw used for recording, editing, and mixing the audio should
> probably be operating at 4x to 8x of the consumer format.

I fully agree: I'm by no means an audio quality expert, but
the calculus lessons tells me that 32bit float is NOT enough for high quality
audio.
(as you said: mix 128voices together and you might loose 7bits in precision
in some cases, that means 24-7 = 17bits ! do some more processing and
we see that we go below the 16bit consumer audio quality !)

Plus most FPUs (at least the Intel ones), process all the their data with
80bit resolution internally, without any speed gain when using 32bit
floats over 64bit doubles.
(there is some speed difference when transfering floats vs doubles,
because of the higher bandwidth required by the latter datatype)

Plus consider the fact that most DSP algorithms on DAWs work with small buffers
(to achieve low latencies when doing RT stuff), that means
almost all involved stuff is in the cache, so that using doubles or floats does
not matter that much (I posted some benchmarks on this list some time ago).

So I see no advantage of using float-based DACs/ADCs over using this approach:

- traditional high quality 24+bit ADCs/DACs

- convert the 24bit input values (from the ADC) to 64bit double precision floats
- do all computations using the double format (because the speed loss over
using 32bit floats is not that big as you might think)
- at output stage truncate/round the 24 upper bits of the 64bit double to a
24bit word (integer) and send it to the DAC.

With the above approach you preserve a high precsion level
when processing audio through the computer.
>
> >But aren't standard high quality 24 bit DACs enough ?
>
> My question to software developers is; is an all float software
> environment desirable enough to warrant a/d with native float output?

IMHO no, because I believe that current DACs/ADCs offer enough precision
to do serious audio work.
The problems mostly lie in the audio software because some apps provide
to little internal precision (by doing all using 32bit floats)).

And some more questions arise when we talk about PPC Altivec / PIII SIMD
instructions:
as we know these instruction can peform up to 4 32bit float operations
simultaneously.
That means great speed, but I think in some cases , the resulting audio
precision will not be enough to be called "professional audio quality".

thoughts ?

Benno.

>
> Tom
>

----------------------------------------
Content-Type: text/html; name="unnamed"
Content-Transfer-Encoding: 7bit
Content-Description:
----------------------------------------


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Sep 24 2000 - 15:35:26 EEST