Re: [LAD] panning thoughts

On Sunday 14 November 2010 06:14:48 Ralf Mardorf wrote:
> On Sat, 2010-11-13 at 19:30 +0100, Arnold Krille wrote:
> > On Saturday 13 November 2010 18:51:17 Ralf Mardorf wrote:
> > > On Sat, 2010-11-13 at 16:26 +0100, fons@email-addr-hidden wrote:
> > > > On Sat, Nov 13, 2010 at 02:57:44PM +0000, Folderol wrote:
> > > > > Paul Davis <paul@email-addr-hidden> 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,
> >
> > Arnold
>
> Using sin/cos still is very time-consuming?
>
> I do understand The Wiki on German better, but the Wiki on English,
> pardon:
>
> "Die Tabellierung aller Werte ist angezeigt bei
> geschwindigkeitskritischen Echtzeit-Anwendungen, wenn diese nur eine
> recht kleine Winkelauflösung
> benötigen." (http://de.wikipedia.org/wiki/Sinus_und_Kosinus#Berechnung)
>
> Loosely translated: Tabulation for rt (when using sin/cos) for small
> angles (what ever a small angle might be) is still faster.

"Winkelauflösung" != "Winkel", that is the angle resolution is not the angle!
So if you want results with bad resolution for your panning, using tabulated
values will work. But that will result in "jumps" in the panning. Better let
the cpu calculate the sin/cos directly. And then realize that approximating
the sinus in that range by another, simpler function speeds up the process to
the point where its faster then looking up a value in a table...
If it was just about small angles less then say 3 degree, the best
approximation of sin(x) is x itself :-)

Have fun,

Arnold

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev