Re: [LAD] panning thoughts

On Sun, 14 Nov 2010 16:03:57 +0100
Arnold Krille <arnold@arnoldarts.de> wrote:

> 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@kokkinizita.net wrote:
> > > > > On Sat, Nov 13, 2010 at 02:57:44PM +0000, Folderol wrote:
> > > > > > Paul Davis <paul@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,
> > >
> > > 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

I don't know if this is at all relevant (prolly not!) but I dimly remember,
from my BBC B days, there was a way of drawing circles using Pythagoras. This
was dramatically faster than using sin/cos.

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev