20 Dec
2006
20 Dec
'06
8:01 p.m.
I understand that LADSPA and friends specifically exclude any
functionality around how to find and load plugins, but it seems that a
lot can be gained by introducing some standards in this area.
As a package of audio apps/plugins for a Linux distro, here are two of
the problems I see:
1. Applications are often hard-coded to look in /usr/lib/ladspa (for
instance), when many systems may require that libraries live somewhere
else (like /usr/lib64/ladspa for x86-64, or /usr/lib32/ladspa for
n32-ABI MIPS Linux). I've had to patch a lot of apps for x86-64 Fedora.
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.
Has there been any discussion around creating a plugin locator/loader
library? It would be nice if one could be written and then widely
adopted by app writers. (I'm not volunteering!)
AG
20 Dec
20 Dec
9:02 p.m.
Hi Anthony,
I guess most of us use the sample enumeration c code included with the
LADSPA sources as starting point. This code expects a LADSPA_PATH
variable to be set. As a fallback, I suppose most programmers
added /usr/lib/ladspa:/usr/local/lib/ladspa, but all of them should
support LADSPA_PATH.
On Wed, 2006-12-20 at 15:43 -0800, Anthony Green wrote:
I understand that LADSPA and friends specifically
exclude any
functionality around how to find and load plugins, but it seems that a
lot can be gained by introducing some standards in this area.
As a package of audio apps/plugins for a Linux distro, here are two of
the problems I see:
1. Applications are often hard-coded to look in /usr/lib/ladspa (for
instance), when many systems may require that libraries live somewhere
else (like /usr/lib64/ladspa for x86-64, or /usr/lib32/ladspa for
n32-ABI MIPS Linux). I've had to patch a lot of apps for x86-64 Fedora.
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.
Has there been any discussion around creating a plugin locator/loader
library? It would be nice if one could be written and then widely
adopted by app writers. (I'm not volunteering!)
AG
--
Leonard Ritter
-- Freelance Art & Logic
-- http://www.leonard-ritter.com
10:14 p.m.
On Thu, 2006-12-21 at 02:02 +0100, Leonard Ritter wrote:
Hi Anthony,
I guess most of us use the sample enumeration c code included with the
LADSPA sources as starting point. This code expects a LADSPA_PATH
variable to be set. As a fallback, I suppose most programmers
added /usr/lib/ladspa:/usr/local/lib/ladspa, but all of them should
support LADSPA_PATH.
from ardour source:
if (ladspa_path.length() == 0) {
ladspa_path =
"/usr/local/lib64/ladspa:/usr/local/lib/ladspa:/usr/lib64/ladspa:/usr/lib/ladspa:/Library/Audio/Plug-Ins/LADSPA";
}
this used across linux and OS X if LADSPA_PATH is not set.
21 Dec
21 Dec
7:56 p.m.
On Thursday 21 Dec 2006 02:12, Paul Davis wrote:
"/usr/local/lib64/ladspa:/usr/local/lib/ladspa:/usr/lib64/ladspa:/usr
/lib/ladspa:/Library/Audio/Plug-Ins/LADSPA"; }
Shouldn't you also have $HOME/Library/Audio/Plug-Ins/LADSPA or some such
on OS/X?
Chris
IANA OS/X developer
26 Dec
26 Dec
11:53 p.m.
On 12/21/06, Chris Cannam <cannam(a)all-day-breakfast.com> wrote:
On Thursday 21 Dec 2006 02:12, Paul Davis wrote:
Yes, that is a valid point. FWIW, that fallback code is not used in
practice in Ardour's OS X release application bundle. It sets
LADSPA_PATH and includes the above directory too.
jlc
"/usr/local/lib64/ladspa:/usr/local/lib/ladspa:/usr/lib64/ladspa:/usr
/lib/ladspa:/Library/Audio/Plug-Ins/LADSPA"; }
Shouldn't you also have $HOME/Library/Audio/Plug-Ins/LADSPA or some such
on OS/X?
20 Dec
20 Dec
10:13 p.m.
On Wed, 2006-12-20 at 15:43 -0800, Anthony Green wrote:
I understand that LADSPA and friends specifically
exclude any
functionality around how to find and load plugins, but it seems that a
lot can be gained by introducing some standards in this area.
As a package of audio apps/plugins for a Linux distro, here are two of
the problems I see:
1. Applications are often hard-coded to look in /usr/lib/ladspa (for
instance), when many systems may require that libraries live somewhere
else (like /usr/lib64/ladspa for x86-64, or /usr/lib32/ladspa for
n32-ABI MIPS Linux). I've had to patch a lot of apps for x86-64 Fedora.
the "standard" specifies that LADSPA_PATH be used if set. thus, distros
that package LADSPA should set LADPSA_PATH in /etc/profile and its
various equivalents. i am still dismayed that distros (and even Intel)
could not agree on a common standard for the path to "the directory
where system-level 64 bit libraries are installed").
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.
that's hard. but then again .... seems like its the job of a package
manager to identify the correct build to install on processor foo,
right?
--p
21 Dec
21 Dec
4:40 a.m.
On Wed, Dec 20, 2006 at 09:11:06 -0500, Paul Davis wrote:
Perhaps, perhaps not. LV2 has the potential to make that easier, as
plugins are in directories, which can have multiple .so files, and they
can be annotated so the host can pick out the right one. They could even
be cross platform that way.
c.f. http://lv2plug.in/ - though the full docs for the directory format are
not yet uploaded.
- Steve
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.
that's hard. but then again .... seems like its the job of a package
manager to identify the correct build to install on processor foo,
right?
3:17 p.m.
On Wed, 2006-12-20 at 21:11 -0500, Paul Davis wrote:
the "standard" specifies that LADSPA_PATH be
used if set. thus, distros
that package LADSPA should set LADPSA_PATH in /etc/profile and its
various equivalents.
Ok, then maybe a good solution for now is to have our ladspa package
generate an /etc/profile.d/ladspa.sh file at install-time that exports a
system-dependent LADSPA_PATH, like
export
LADSPA_PATH=$HOME/.ladspa/sse2:$HOME/.ladspa:/usr/local/lib/ladspa/sse2:/usr/local/lib/ladspa:/usr/lib/ladspa/sse2:/usr/lib/ladspa
...for sse2-enabled platforms (for instance).
Then plugin packagers can build and install any number of different
plugin builds as long as they land in directories known by the ladspa
package installer.
Same goes for DSSI_PATH.
AG
4:39 p.m.
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.
-- Fernando
5:32 p.m.
On Thu, 2006-12-21 at 12:39 -0800, Fernando Lopez-Lezcano wrote:
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 think one big win will be with compiling certain plugins to use SSE
floating point in order to eliminate denormal delays.
As for creating multiple packages... I don't yet know to what extent the
Fedora infrastructure (yum, rpm, etc) will handle this. Building them
all in one package seems like the simplest thing for now and we can hack
the ladspa spec file to generate /etc/profile.d/ladspa.sh based on the
contents of /proc/cpuinfo at install time. The plugin packages aren't
that big anyways.
AG
23 Dec
23 Dec
9:39 a.m.
Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> writes:
On Wed, 2006-12-20 at 15:43 -0800, Anthony Green
wrote:
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(a)db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>
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. 
25 Dec
25 Dec
10:19 a.m.
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(a)delysid.org>rg>:
Fernando Lopez-Lezcano <nando(a)ccrma.Stanford.EDU> writes:
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(a)db.debian.org
: :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
`. `'
`- <URL:http://delysid.org/> <URL:
http://www.staff.tugraz.at/mlang/>
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.
6534
days inactive
6540
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
9 participants
participants (9)
-
Anthony Green -
Chris Cannam -
Fernando Lopez-Lezcano -
Jesse Chappell -
Leonard Ritter -
Mario Lang -
Paul Davis -
Stefano D'Angelo -
Steve Harris