Re: [LAD] panning thoughts

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, 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.
>
> 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
rncbc@email-addr-hidden
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev