Re: 64bit processing - Why?
Re: 64bit processing - Why?
- Subject: Re: 64bit processing - Why?
- From: Justin Carlson <email@hidden>
- Date: Fri, 31 Jul 2009 00:52:09 -0400
Bill Stewart wrote:
I believe it is possible to configure SSE registers to deal with
double (2) or single precision floats (4) - that is one difference
between SSE and Atlivec because Altivec just dealt with single
precision floats.
They are. SSE registers are 128 bits, which breaks down to 4 floats or
2 doubles for the registers, instructions for each width do exist. I
am not certain if there are omissions where there is no double
precision counterpart (or vice versa), or whether some calculations
are calculated internally to different widths.
Point(1)
DSP processing
I'd also add (or restate) my original comment that it is not
uncommon to use double within the DSP, but we have generally found
it more efficient to use doubles sparingly where the extra precision
is worth the CPU cost, and then other places to use single precision
where there is no gain in using doubles. This is really a case by
case analysis and knowing the affect of precision on your filter
designs and uses.
I'd agree that this is case by case, I will also say that the audible
results/tradeoffs are subjective.
I did a lot of testing in this regard, the best conclusion that I came
was:
1) The processing I was doing required some calculations at 64
2) The convsersion cost was significant
3) The time required to calculate at double precision is not half as
fast (as one might figure)
For the tests I did, and for the processing I was doing in the tests,
I concluded that I was simply wasting my time by trying to figure out
which format was best for a particular algorithm or combination of
algorithms, because fp conversions/mixed precision arithmetic can take
more time (compared to processing entirely in double precision), or it
can take less - it is a case by case basis. I could spend a
significant amount of time finding the best balance of these
processors throughout development, comparing sound and performance
using different widths and I would end up with marginal progress after
a significant time investment because I would simply be comparing
conversion time vs different degrees of precision. Again, each
processor and each developer is different, and I don't use double
precision for every processor, but I maintain double precision in
complex processors from in to out because evaluating each processor in
my tests resulted in (virtually) no progress at the end of the day. If
one has the ability to separate larger groups of processors into
single or double, it can improve performance and memory use. I don't
consider myself lazy regarding performance or optimization (quite the
opposite). I do not recommend that developers blindly use my findings
in their implementations, but that they find the best solutions for
their projects for themselves (assuming balancing performance and
precision is important).
Point(2)
AUHAL
As for the output stage. The best DAC/ADC performance I've seen that
is commercially available is within the 110 to 120 dB range. Its
hard to get up to the 120dB mark. That still leaves 4 bits of
dynamic range unused from a 24 bit signal path (which single
precision floats can represent). So, most (if not all shipping at
least) available converters use 24bits and as Ethan explained, this
is quite a wide dynamic range (bleeding ears 'n all)!
Ok, so going from the single float to the 24bit int. You have NO
loss or precision when doing this conversion. There is no truncation
or other loss of resolution in this transformation (provided that
the float is within the nominal range of -1 < 1).
If you have a double precision signal chain, you can do the
dithering yourself to single precision float. That is then
faithfully preserved through the rest of the signal chain to the
24bit converters.
So, I don't see how using AUHAL poses a problem here. But, maybe I'm
just stupid!
Bill
Since I originally posted, I have been able to think of a reasonable
application, such that an audio device manufacturer _could_ want I/O
streams at a higher precision. That case would be interfaces with
integrated DSP and mixers.
Metric Halo's Mobile I/O interfaces are a good example for this:
1) Their mix buss is 80 bit, fixed
2) They have multiple I/O options and an extensible interface
3) They offer a good amount of DSP power and algorithms onboard
All things considered, would Metric Halo *want* any signal format
wider than 32 bits? I don't know the answer - it would proportionally
reduce the number of I/O streams that their interface could support on
Firewire bus, and their interfaces already push the limits regarding
firewire throughput. Nonetheless, it is one example where a
manufacturer *could* want more precision (even if the motivation were
driven by user demand or marketing).
Best,
Justin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden