Well, this topic truly interests me. I am the main developer of FreeADSP, my name's Stefano, and this is the first time I write in here.
You know, in my application I'll try to make different kind of audio processing plugins work together using a compatibility layer (plugin loader plugins).
I realize that it could be something that other people might be interested to as well, so maybe it's more convenient for the whole community if we develop a kind of wrapping library for different plugin architectures which also contains info on how to retrieve plugins (maybe such as fontconfig does for fonts, and maybe we could also use SWIG).
What do you think about it? Let me know!
Stefano
2006/12/23, Mario Lang <mlang@delysid.org>:
Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU> writes:
> On Wed, 2006-12-20 at 15:43 -0800, Anthony Green wrote:
>> 2. We build binaries for the lowest common denominator, so the plugins
>> you'll find in Fedora, for instance, don't take advantage of SSE
>> hardware or instruction scheduling for different processors. This can
>> make a huge difference. What would be nice is if we could distribute an
>> RPM containing a plurality of plugin builds, and then have the
>> application load the plugin matching the capabilities the execution
>> platform.
>
> Perhaps it would be possible to create packages for "i686" in addition
> of packages compiled for the "i386" architecture? I think I used to do
> that for my Planet CCRMA packages... but I don't think I ever saw a
> noticeable difference in performance.
I still think the only true way to solve these issues is proper
runtime CPU detection, and optimized routines for specific CPUs.
This way, you do not extensively duplicate data. And you keep the
installation process simple for your users, and you can distribute
your packages in a standard way, without needing to care
about the i686 or whatever details.
JACK already does such a thing for its SSE mixing code...
mplayer also does something similar.
Simply maintain some function pointers for your algorithms that you setup
at init time after you figured out what the best implementations are.
You could even give them a spin by comparing performance at runtime,
and deciding on the results (the linux kernel does that for crypto
and raid algorithms).
You can even have gcc help you optimize for specific targets, simply
put target-specific code in a separate C file, compile it with your
optimisation options, and make sure in your program, the code only
gets called if this target has been detected.
This is especially cool if you think about a user changing ther hardware
components, but leaving their dsk driver untouched. Imagine you pull
your disk out of a certain machine, put it into another (with another CPU
type), and boot up. With runtime CPU detection, you get best possible
performance immediately, no need to reinstall any packages.
--
CYa,
Mario | Debian Developer <URL:
http://debian.org/>
.''`. | Get my public key via finger mlang@db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:
http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>