Subject: Re: [linux-audio-dev] LADSPA 64bit FP support ?
From: Karl W. MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Sun Mar 26 2000 - 07:28:04 EEST
On Sun, 26 Mar 2000, David Olofson wrote:
>
> Ok, sorry. :-) I must have gotten the impression that the point was
> that *only* 64 bit data should be supported - which is just a waste of
> bandvidth for most systems.
>
No problem - it seems we are very much in agreement that no one data type
will be sufficient for all situations.
>
> Yes, but there mustn't be a need to recompile unless we're enforcing
> the GPL as a requirement for using the API. It would be nice if all
> plugins case as source, or compiled for the major data types, but I'm
> not expecting that to happen...
I'm sure a lot of people thought that what RMS envisioned wouldn't happen
as well. Don't want to preach to the choir (is that strictly a southern
phrase?) but requiring or strongly suggesting opensource should be
considered if a majority of people want this (please don't flame me if
this has been gone over before).
>
> Also, I hope I'm not giving the impression of being as rude as to
> point someone out as the one behind That Other OS! ;-)
Well, maybe I am defensive because I am Bill.
> > What type of data can you not transfer between plugins as vector or scalar
> > floats that the data types that you added will allow?
>
> In theory you cold probably pass anything that way, but if you're
> going to use MMX, deal with high frequency data (like from digital
> oscilloscope cards) or video data, it's not very suitable.
This is a philosophical road we probably don't want to go down, but I
think that assembler is better written by compilers and I don't want to
write for specific processors (there is always something better just
around the corner anyway). Don't the new instructions for the PIIIs that
magically accelerate the internet do floating point anyway? Don't know
enough to comment on the other two. My only thought is that it would be a
shame to require extra code in 99 percent of the plugins just to
facilitate a few plugins that are probably going to require special hosts,
etc. anyway. You never know, though, running audio through plugins
designed for video might be fun . . .
>
> One could argue that this API will only be used for "power consumer"
> through high end audio, and that plugins using different data types
> will never run under the same host, bit I think that's too
> restrictive.
>
Is using floats really that steep a requirement? Super Collider/Max MSP
does surprisingly well on less than the latest and greatest. Also, hosts
always have the option of running the plugins in less than real time.
> > You have it backwards - I want to make it easier to write plugins not to
> > write hosts. It is a choice between making every plugin potentially do
> > lots of conversions and handle lots of data types (and there will
> > hopefully be thousands of plugins) or making a few (or at least a lot less
> > than plugins) hosts support data conversions.
>
> * A plugin will not be forced to do anything but declaring what
> format is used for each one of it's ports.
>
> * A plugin may be compiled in different versions with different
> formats, if the developer is nice enough to follow the
> recommendation of providing plugins for the major data types.
My whole goal is to make it so that providing for the major data types
only requires a recompile - as soon as the pesky integers come into the
picture everything gets messy.
>
> * Host do not have to support *any* data types. They can get
> away with uning only the element size field of the data type
> descriptors, and use interface/driver plugins to communicate
> with the outside world.
>
> * Hosts are required not to allow direct connection of ports
> of different types.
>
> * Hosts may use an array of plugins, or inline code to convert
> between formats as needed. This can also be done manually by
> the user for the simplest hosts.
>
This is what scares me - it is likely that these conversions will
have an adverse effect on sound quality and performance. Maybe if the
entry and exit points of the plugin network had provisions for conversions
. . . but this gets ugly and is, in my mind, the job of the host.
Especially since the types of conversions are likely to change rapidly
(with all of the compressed formats, multichannel digital, etc.). This
type of code is better placed in a library for host writers to use.
An end user is not likely to have a strong preference about whether or not
the plugin network is floats or roman numerals as long as it sounds good
and all of the plugins work (I certainly feel this way when I am a user).
What they are likely to care about is getting sound in and out of lots of
strange formats that have no business at all in a plugin spec for any
level (professional->fisher price tape deck). I see little hope of
providing for these types of conversions in a clean, consistent manner
within a, hopefully, fixed API specification.
> That is, plugins are basically coded the same way as if the data
> type were fixed at compile time, but instead of putting the data
> type ID in the version code, there's one field for each port. Data
> typing is still static after compile time, but you may have ports of
> different types on the same plugin.
>
> The host gets to do the work, actually. It has to compare the data
> type IDs before connecting ports, and take some action if they're
> different. It also has to understand the data types it wants to
> operate on directly, unless it leaves that to special purpose
> plugins. At can get away with understanding only one type, and using
> converter plugins, just like when connecting incompatible ports.
>
Your whole plan is useful only if individual plugins can have multiple
data types and this is where I am just not convinced. So far the
rationalization for this is:
- Preferences of coder/user
- Ability to support non-audio data
- Need for integer types of MMX/Altivec(?)
I think that everyone would prefer floats unless using ints would give a
huge performance increase (but if I am wrong please tell me). I doubt
using ints would give that big a boost except if SIMD instructions were
used - if this is really worth it the plugin can do the conversion
internally. Supporting non-audio data is most likely just going to annoy
audio plugin writers and produce poor API for video or whatever. If
people are serious about making this a generic plugin api I think we
should look into passing arbitrary, self typed messages (like Max Atoms
but with more types). This would allow for the passing of, for example,
pointers to buffers of video data. If the goal is going to be changed to
making a generic API it should be made *completely* generic.
Karl
_____________________________________________________
| Karl W. MacMillan |
| Peabody Institute of the Johns Hopkins University |
| Network and Telecommunications Services |
| karlmac_AT_peabody.jhu.edu |
| 410/659-8297 |
-----------------------------------------------------
This archive was generated by hypermail 2b28 : Sun Mar 26 2000 - 08:02:31 EEST