Re: 64bit processing - Why?
Re: 64bit processing - Why?
- Subject: Re: 64bit processing - Why?
- From: Justin Carlson <email@hidden>
- Date: Thu, 30 Jul 2009 21:33:01 -0400
Hi Ethan,
I hope I have not miss understood: we are talking about the numeric
format used *between* processing units not the format used within
the unit correct?
Right. Internally, AUs may render using any type they choose (or mixed
types). When float (32 bit) is the standard, as it is currently, this
requires more conversions than necessary, for no gain, and with the
potential for audible signal degradation when many double precision
calculations are taking place. By allowing the plugin to declare that
it supports 64 bit I/O, signal quality, CPU, and potentially memory
can be preserved.
I have no complaint about using double precision numbers were non-
linear, large coefficient array FIR or recursive IIR DSP operations
are being performed. In such situation, it may be and often is
called for. But why force all the other simple summing and scaling
that goes on in the chain before and after to be double precision
just for the sake of a section of DSP code that needed the precision
internally?
Ultimately, the internal type ('resolution' used by the mixer) should
be determined by the host, and the host should perform any necessary
conversions (IMO) to interface with the plugin. Therefore, this common
practice reduces the benefits of the host developer's preference, if
it is double. Hosts can benefit by processing at this level, whether
this is worthwhile needs to be determined by the host developer. I
can't imagine why any host developer that wanted to mix at 64 bit
would not want 'double support', for multiple reasons.
I bet the overhead of doing a double to single with dither before
coming out of a piece of DSP code is small compared to having to
drag doubles thought the whole audio chain.
Not really. Mixed precision arithmetic and conversion is expensive,
whereas the increased memory requirements and throughput are trivial
(in my experience). This also assumes the machine has enough memory,
and so on. For the host, 'double support' means twice the memory
requirement for temp buffers and conditional conversions between
stages. For plugins, it means they may be able to allocate *fewer*
temporary buffers and have no conversions at the I/O stage. So memory
isn't a big deal until track counts get high, even then, it is
implementation/case dependent. Based on plugins used, this could
require less memory. If you're still with me, it will require more
memory throughput, but that is less costly than precision conversion
and/or mixed precision arithmetic.
J
_______________________________________________
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