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

<br><br>What do you think about it? Let me know!<br><br>Stefano<br><br><div><span class="gmail_quote">2006/12/23, Mario Lang <<a href="mailto:mlang@delysid.org">mlang@delysid.org</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Fernando Lopez-Lezcano <<a href="mailto:nando@ccrma.Stanford.EDU">nando@ccrma.Stanford.EDU</a>> writes:<br><br>> On Wed, 2006-12-20 at 15:43 -0800, Anthony Green wrote:<br>>> 2. We build binaries for the lowest common denominator, so the plugins

<br>>> you'll find in Fedora, for instance, don't take advantage of SSE<br>>> hardware or instruction scheduling for different processors.  This can<br>>> make a huge difference.  What would be nice is if we could distribute an

<br>>> RPM containing a plurality of plugin builds, and then have the<br>>> application load the plugin matching the capabilities the execution<br>>> platform.<br>><br>> Perhaps it would be possible to create packages for "i686" in addition

<br>> of packages compiled for the "i386" architecture? I think I used to do<br>> that for my Planet CCRMA packages... but I don't think I ever saw a<br>> noticeable difference in performance.<br><br>

I still think the only true way to solve these issues is proper<br>runtime CPU detection, and optimized routines for specific CPUs.<br><br>This way, you do not extensively duplicate data.  And you keep the<br>installation process simple for your users, and you can distribute

<br>your packages in a standard way, without needing to care<br>about the i686 or whatever details.<br><br>JACK already does such a thing for its SSE mixing code...<br>mplayer also does something similar.<br><br>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).

<br><br>You can even have gcc help you optimize for specific targets, simply<br>put target-specific code in a separate C file, compile it with your<br>optimisation options, and make sure in your program, the code only<br>

gets called if this target has been detected.<br><br>This is especially cool if you think about a user changing ther hardware<br>components, but leaving their dsk driver untouched.  Imagine you pull<br>your disk out of a certain machine, put it into another (with another CPU

<br>type), and boot up.  With runtime CPU detection, you get best possible<br>performance immediately, no need to reinstall any packages.<br><br>--<br>CYa,<br>  Mario | Debian Developer <URL:<a href="http://debian.org/">

http://debian.org/</a>><br>  .''`. | Get my public key via finger <a href="mailto:mlang@db.debian.org">mlang@db.debian.org</a><br> : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44<br> `. `'<br>   `-      <URL:

<a href="http://delysid.org/">http://delysid.org/</a>>  <URL:<a href="http://www.staff.tugraz.at/mlang/">http://www.staff.tugraz.at/mlang/</a>><br></blockquote></div><br>