[LAD] panning thoughts

Arnold Krille arnold at arnoldarts.de
Sat Nov 13 18:30:16 UTC 2010

On Saturday 13 November 2010 18:51:17 Ralf Mardorf wrote:
> On Sat, 2010-11-13 at 16:26 +0100, fons at kokkinizita.net wrote:
> > On Sat, Nov 13, 2010 at 02:57:44PM +0000, Folderol wrote:
> > > Paul Davis <paul at linuxaudiosystems.com> wrote:
> > > > there's an awful lot of math for which a modern processor can compute
> > > > the answer faster than it can look it up. this is one such example
> > > > (as fons noted), but there are many others. this started changing
> > > > about 8 years ago, and its only gotten more true since then.
> > > 
> > > Oh dear. I didn't realise I was so far out of date :(
> > 
> > It's absolutely true.
> > 
> > Note that the calculation I posted earlier runs entirely on
> > the FP processor, and two variables, q and d, will probably
> > only exist there and never be written to memory. If it takes
> > any time at all, the CPU can meanwhile do something else,
> > such as getting the pointers to the audio data it will need
> > later. Using a LUT will mean the CPU has to do all the work,
> > which includes getting the base pointer and calculating the
> > required offset(s).
> Just to ensure you aren't talking about different claims.
> Is math even faster, as e.g. 4 states for left, 1 for centre and 4
> states for right, provided e.g. by an array? Or are you thinking about
> nearly stepless panning?

Unless your memory runs (and is connected) at the same speed of the processor 
(which afaik no platform has, even the first and second cache run at lower 
speeds), simple math of only a limited number of operations is always faster 
then getting stuff from memory. Todays processors contain even more 
optimizations for fast and parallelized math.
The trick Fons showed is about doing the pan calculations in simple math 
instead of using trigonometry which would require complicated functions like 
sin/cos to be called or tables from memory to be checked.

Have fun,

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20101113/5deabe44/attachment.pgp>

More information about the Linux-audio-dev mailing list