linuxaudio.org

--nextPart14050020.WL4jXOunrO

Content-Type: Text/Plain;

  charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable
On Sunday 14 November 2010 06:14:48 Ralf Mardorf wrote:

quoted text
> 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  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.

> > > > >=20

> > > > > Oh dear. I didn't realise I was so far out of date :(

> > > >=20

> > > > It's absolutely true.

> > > >=20

> > > > 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).

> > >=20

> > > Just to ensure you aren't talking about different claims.

> > >=20

> > > 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?

> >=20

> > 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.

> >=20

> > Have fun,

> >=20

> > Arnold

>=20

> Using sin/cos still is very time-consuming?

>=20

> I do understand The Wiki on German better, but the Wiki on English,

> pardon:

>=20

> "Die Tabellierung aller Werte ist angezeigt bei

> geschwindigkeitskritischen Echtzeit-Anwendungen, wenn diese nur eine

> recht kleine Winkelaufl=F6sung

> ben=F6tigen." (http://de.wikipedia.org/wiki/Sinus_und_Kosinus#Berechnung)

>=20

> Loosely translated: Tabulation for rt (when using sin/cos) for small

> angles (what ever a small angle might be) is still faster.

"Winkelaufl=F6sung" !=3D "Winkel", that is the angle resolution is not the =

angle!

So if you want results with bad resolution for your panning, using tabulate=

d=20

values will work. But that will result in "jumps" in the panning. Better le=

t=20

the cpu calculate the sin/cos directly. And then realize that approximating=

=20

the sinus in that range by another, simpler function speeds up the process =

to=20

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=20

approximation of sin(x) is x itself :-)
Have fun,
Arnold
--nextPart14050020.WL4jXOunrO

Content-Type: application/pgp-signature; name=signature.asc

Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAkzf+mAACgkQuYLL1cDjHx1BVwCdHBaLNRl1SV0DOv0J3ccSG7dy

ryoAnjOKlZYJxRHZhno6SYEB8cCNDWrF

=R/pf

-----END PGP SIGNATURE-----
--nextPart14050020.WL4jXOunrO--