linuxaudio.org

On Sat, 2010-11-13 at 19:30 +0100, Arnold Krille wrote:

quoted text
> 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  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.
My question: It's better to avoid using sin/cos and instead to use Fon's

trick?!
Hence Qtractor (Rui) better shouldn't use sin/cos?
Thanx,
Ralf
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev