Re: Stereo > Mono Downmixing on iOS
Re: Stereo > Mono Downmixing on iOS
- Subject: Re: Stereo > Mono Downmixing on iOS
- From: Richard Dobson <email@hidden>
- Date: Mon, 04 Apr 2011 10:24:05 +0100
On 04/04/2011 09:25, Brian Willoughby wrote:
On Apr 3, 2011, at 23:49, tahome izwah wrote:
2011/4/3 Richard Dobson <email@hidden>:
Summing is not the only thing music software has to do - for signal
processing tasks, it was found a while ago that 32bit floats were not
quite
sufficient for many tasks, especially considering high-resolution
formats.
Care to share any pointers?
...
Apart from SRC, many filtering and other frequency-domain DSP benefits
from 64-bit implementation. Granted, 32-bit is often enough to suffice,
given that floating point adapts to small signals quite well. I assume
that there are filters which benefit from 64-bit math just as much as SRC.
Sometimes the 32/64 differences only appear if you run a sufficiently
long soak test on your algorithm. One anecdote to report:
A while ago I had the chance to work on a very specialized parallel
computing accelerator card developed for the HPC community; basically to
see if it offered any traction for computationally heavy audio work. I
got a simple additive synth engine going on it, generating pure
band-limited square waves and sawtooths with, say, up to 400 partials
for very low notes. To begin with, I coded it all in 32bit floats, for
no other reason than that I was following some sample code from the
manual that used floats. I monitored the output on a scope. It was all
fine for ten minutes or so, so I left it all running while we went off
to have coffee. When I returned perhaps 40 mins later, while it still
sounded OK the shape of the waveform had deteriorated beyond the point
of recognisability. Clearly the small phase accumulation errors had
resulted in cumulative quasi-random phase shifts.
To cut the long story short - by changing the code to use doubles (which
was in fact one of the selling points of the card, when there were
essentially no floating-point parallel accelerators around supporting
full IEEE doubles in hardware; now many GPU cards offer it) the
waveform remained in perfect shape even after running for 24 hours. I
leave it as an exercise for people to work out how many phase
accumulation additions plus wraparounds per partial that would involve,
at 44100Hz.
Similarly, running the sliding phase vocoder (SPV - DFT frame updated
every sample), it became clear early on that 32 floats were not enough,
it does need double precision. The two processes are closely related, in
that SPV resynthesis is by oscillator bank.
I would finally note that fixed point or integer processing offers some
widely reported advantages over floating-point, in that such things as
comparisons are exact - no messing about with epsilon differences, etc.
Truncation noise n'stuff can be exactly cancelled out. So an oscillator
iteration function (or filter for that matter) can sit exactly on the
unit circle, never migrating outside it into overflow. So there is a
sense in which integer processing (when skilfully programmed - not
something I know how to do!) can get more performance out of a smaller
word size than the computer based floating point solution can manage.
64bit words may be overkill, but the top dsp devices do support
accumulators of at least 48bits, so you can do a full 24*24 multiply.
The SHARC (as used in the Creamware cards) is nominally 32bit but has
40bit registers, IIRC, and can flip between integer, fixed and float
with a single machine instruction.
Richard Dobson
_______________________________________________
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