14 Nov
2010
14 Nov
'10
12:17 p.m.
On 11/14/2010 05:14 AM, Ralf Mardorf wrote:
On Sat, 2010-11-13 at 19:30 +0100, Arnold Krille
wrote:
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
rncbc(a)rncbc.org
On Saturday 13 November 2010 18:51:17 Ralf
Mardorf wrote:
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?
On Sat, 2010-11-13 at 16:26 +0100,
fons(a)kokkinizita.net wrote:
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 On Sat, Nov 13, 2010 at 02:57:44PM +0000,
Folderol wrote:
> Paul Davis <paul(a)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?