[gmpi] Re: Topic 7.1: Channel Formats
- From: Steve Harris <S.W.Harris@xxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 4 Jun 2003 18:54:57 +0100
[appologies for the long mail, this is a complex and important subject]
On Wed, Jun 04, 2003 at 12:22:35PM -0400, RonKuper@xxxxxxxxxxxx wrote:
> >>>
> I've not yet seen any convincing arguments or test-cases to support the need
> for double audio i/o or interleaving.
> <<<
>
> (1) Need for double audio: DSP "kernels" require double precision float to
> retain sufficient accuracy. A modular synth builder or effects builder
> environment will have processing elements that are in essence DSP kernels,
> such as biquads, delay lines, etc. We should be able to package these
> processing elements as GMPI objects. Therefore, if we don't allow them to
> stream doubles to each, they cannot have the math precision needed.
There is signicant evidence to the contrarary, eg. jMax, pd and
SyncModular. They have very low-level processing objects, and graphs of a
few hundred objects are realtively common.
I have just built my own benchamrk (http://plugin.org.uk/32vs64/), and it
seems to me that using float as i/o is not an issue. After 1000
interations of extreme gain changes the noise in the 32bit i/o simulation
is around the -300dB mark. This should be equivalent to 1000 float i/o
plugins connected in series, with each one doing roughly a +40dB gain on
input and -40dB on output. Input and output gain are not equal. I think
that's basicly pathelogical.
There may be bugs in my code of course (please check!). The directory
contains the C source, the x86 assembler output from my compiler, an ELF
binary and the results of running with 100 and 1000 interations.
> (2) Need for interleaving: Surround applications are likely to have serial
> chains of effects processors that accept multichannel audio. Applying
> volume/pan to a multichannel stream is akin to a vector dot product, where
> one vector is the interleaved sample value and the other is the per-channel
> gain. Vector dot products can be performed more efficiently, with less
> cache pollution, using SIMD instructions. Therefore, if we don't allow
These examples can equally well be performed on uninterleaved data. The
difference is that with interleaved data you loose efficiency if the
number of channels is not a multiple of 4 and with uninterleaved data you
loose efficiency if the number of samples is not a multiple of 4.
> interleaving, surround applications are going to suffer degraded performance
> because they won't be able to fully leverage parallelism -- they will be
> forced to do surround gain as uninterleaved SISD, whose performance has been
> deprecated on newer Pentium systems.
One of us is missing something ;) The only time theres any advantage to
swizzle the data is when you have to perform dependent operations (eg. IIR
filters) and then I suspect the cost of swizzling is lost in the noise.
A simple gain change or pan can be done with the same vector multiply you
would use with interleaved data.
Even when you are performing IIR operations you can aviod swizzling by
cascading the channel buffers.
- Steve
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
