Subject: Fw: [linux-audio-dev] SAOL/Quasimodo
From: Ellis Breen (ellisbreen_AT_bigfoot.com)
Date: Fri Sep 29 2000 - 05:46:35 EEST
----- Original Message -----
From: Ellis Breen <miminon_AT_hotmail.com>
To: <linux-audio-dev_AT_ginettew.musique.umontreal.ca>
Sent: Friday, September 29, 2000 3:06 AM
Subject: [linux-audio-dev] SAOL/Quasimodo
> >wait - how can a firewire device access host RAM other than through
> >the PCI bus ? is there some alternate route to RAM ?
> Sorry, someone gave me some misleading figures on Firewire speed... turns
> out it's only about 40% the speed of PCI66 (1Gbs) thus far... although
they
> are
> attempting to match that. Still, we need faster transfer busses for
> auxiliary
> hardware - AGP manages it...
>
> Someone suggested Creamw_AT_re use the AGP4x slot and leave the
> PCI slots to the graphics cards. It seems a shame to waste all this
upcoming
> RAM bandwidth (4Gbs for the new Athlon motherboards) on GPUs/x86s...
> maybe a 16-way Crusoe/PPC/Thumb10 (running PPC and ARMLinux
> respectively of course ;-) ) setup would be worthy though...
>
> > >Are potential optimisations lost in the translation to C by SFront/SFX?
> > >Could one spec up a superior intermediate API for SAOL to machine code
> ..
> > There's some wins possible in that direction (for a micro-optimization
> > example, many table operations could go better with ASM-optimized
rounding
> ..
> > > yikes. please don't use SAOL. saol was an excellent reformulation of
> > > Csound, but as a general purpose synthesis/fx language, i consider it
> > > to be weak and to have a number of specific defects.
> .
> > Let's take Paul's judgement of SAOL vs Quasimodo as a sound language
> > as fact for a moment -- I have my own opinions, but its irrelevant to
> ..
> > It may seem like a minor quibble, but its really important to
> > understand that Quasimodo is *NOT* a sound language. Quasimodo
> > dynamically loads the parsers+compilers for the sound languages used
> > by the modules it runs, and does not contain *any* built-in language
>
> > > But on the other hand, there are lots of other systems where the
> > > installed base of MP3 as a standard overwhelms efficiency gains you'd
> > > get by moving to a technically superior format.
>
> > This is true, without a doubt. What's sad for me here is that MP3 is
> > not a programming language, and when MP4-SA is used in the vast
> > majority of the systems where it will be deployed, it will also not
> > really be a programming language in the sense that no human will sit
> > down and express algorithms with it.
>
> Paul, I checked out Quasimodo and it looks very interesting. I actually
> had Lexx/Flex and Yacc/Bison in mind when I was considering the proposed
> intermediate API for SAOL compilation. It strikes me that one could define
> a superior Lexx grammar and Yacc implementation for SAOL/CSound than
> that of the C language... Is it not true that optimisation at an abstract
> level
> dictates implementation at a machine level?
>
> So maybe Quasimodo would be a suitable umbrella for both my doctyped XML
> idea and my
> intermediate API? I have no desire to re-invent the wheel (unless "Wheel
MK
> 2" is significantly better). If you (or I) could create a sequencer module
> for Quasimodo, then we could encapsulate everything neatly. I loathe
nothing
> more than unnecessarily replicated effort so the more one can control and
> setup
> everything in the same place, the better.
>
>
>
>
This archive was generated by hypermail 2b28 : Fri Sep 29 2000 - 06:12:31 EEST