On 11/14/2010 05:14 AM, 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, [email protected] wrote: >>>> On Sat, Nov 13, 2010 at 02:57:44PM +0000, Folderol wrote: >>>>> Paul Davis <[email protected]> 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? >
as said, for qtractor the panning coefficients are computed _only_ when the pan widget slider changes. the simple one-shot calculation is carried out in gui thread context so it does not add a cycle whatsoever to dsp load ;) cheers -- rncbc aka Rui Nuno Capela [email protected] _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
