Subject: [linux-audio-dev] Re: LADSPA with dynamic datatype and multichannel support released !!
From: David Olofson (david_AT_gardena.net)
Date: Thu Mar 30 2000 - 02:59:44 EEST
On Mon, 27 Mar 2000, Benno Senoner wrote:
> - hosts and plugin can support an arbitrary number of datatypes.
> the host can lookup the supported datatypes and choose amongst one of them
>
> - plugins can support DIFFERENT datatypes for input and outputs.
> The restriction is that you can have only one input datatype and one output
> datype.
> For example if you set input datatype = float and output datatype = double
> the both input CONTROL ports and input AUDIO ports have to use the float
> type, while output CONTROL ports and output AUDIO ports have to use double.
>
> Allowing per-port datatype would make things much more complicated for host
> and plugins, since our goal here is audio streaming not events.
>
> For example if you have a lowpassfilter running in 32bit float mode, then the
> cutoff frequency will be a float too, when you use the 64bit version, the
> parameter becomes 64bit too. I think that is not that much restrictive.
> Notice that input and output is decoupled.
> if you run a plugin with input dataype=float and output datatype=double
> (assuming that it supports different datatypes for input and output)
> the input control ports become float and the output control ports become
> double.
> Too much restrictive ? (IMHO it's not worth the trouble change this)
Not sure, but it seems to make sense... Control values have to be
scaled to the resolution of the data before any "anti-zipper
filtering" anyway for the extra resolution to make sense, so the
restriction should actually reduce the risk of extra conversions when
dealing with optimized nets. (That is, nets using optimized plugins
and a single data type.)
> I opted for separate input and output datatypes since it will allow
> to implement easily the famous CONVERTER-PLUGINS.
> (e.g. the ones which Juhana was talking about: double->16bit int converters
> etc) there is no limit about combinations.
> Each datatype is described by a DataTypeDescriptor:
>
> typedef struct {
> int BitSize;
> int BitAlign;
> int Type;
> char *Name;
> char *Description;
> } LADSPA_DataTypeDescriptor;
>
> let's take the famous 'float' datatype (32bit)
>
> BitSize=32
> BitAlign=32 (aligned to its size)
> Type=LADSPA_DATATYPE_NUMERIC | LADSPA_DATATYPE_FLOAT (just informational flags)
Perhaps the Type field should be called Flags...?
> Name="FLOAT32"
> Description: if the plugin wants, it can supply a brief description about the
> datatype.
I like that. More intuitive than my all-in-32-bits encoding, and a
huge (practically unlimited) namespace to avoid future problems.
More overhead for checking connections, but engines may use hash
codes or internal enumerations for local connections to get around
that.
> Notice that this design allows even streams of single bits to be streamed
> between plugins.
Good idea. :-) Makes sense for low bit rate ADPCM data and the like.
> Performance: SAME as old LADSPA since there is no runtime overhead
Well, there is RT instantiation and connecting... :-)
> Multichannel capabilities:
[...]
> plus there is a flag if number of input channels has to match the number of
> output channels
Problem: What about plugins that have a fixed inputs/outputs
relation which is not 1:1?
> The API supports interleaved multichannel mode too:
> basically instead of using N (N=number of channels) ports with data-rate of R,
> you use one singe port with datarate N*R.
> But this will ONLY be used in very special cases, for example
> there could arise the need to process a 100 track interleaved stream
> with specialized multichannel plugins. In this case the interleaved mode
> can increase the performance quite a bit, but again , "normal" plugins and
> hosts will use the separate channel mode. (one port for every channel)
Ok.
> (Notice: mentally sick people could even combine the interleaved multichannel
> mode with bit fields, for example streaming multiple interleaved single-bit
> streams over arrays of bytes. David, u like this ? :-) )
*hehe* I dunno... Could be useful for some kind of high performance
real time logic simulator or something... :-)
> In the case of a plugin supporting multiple datatypes ,
> since the datatype is passed to the instantiate function, some of the
> functionpointer assignments have to be moved from the descriptor()
> function to the instantiate() function since these are datatype dependent.
> eg. a plugin supporting float and double would have two run() functions
> run32() and run64() the Descriptor->run pointer would be assigned based
> on the datatype passed to the instantiate function.
> It's really easy to add a new datatype to a plugin.
>
>
> What is still missing is runAdd() support, it will be added as soon we
> agree on the setGian() issue (per-channel setGain etc).
> Any proposal ?
It's pretty straightforward with the event system - just send SetGain
events to the output channels. (No hard input/output distinction, as
the LADSPA channel table is used. Unique channel indexes to use for
this kind of stuff, that is.)
More problematic with the pure LADSPA model, though, as there's no
obvious way to map control inputs to audio outputs... Port N = audio
out, port N+1 = output gain for port N or something?
The setGain() call corresponds rather closely to the event system
version - the main difference is that the event system timestamps the
data and sends it to the event input port rather than passing it
through a function call.
The disadvantage with setGain() is that it's out-of-band in relation
to the rest of the normal process time API (the run() call and the
ports.), which makes the thinnest intersection of the interface
fatter. Not good for cross-thread connections and the like, as the
setGain() calls will need some RPC mechanism to be passed safely and
at the right time.
> If some people are still fixated on the float-only method, then we should vote
> which version to use.
Won't make a difference. Unless all developers agree, there will
probably be at least two similar but incompatible APIs, which is
what we (most of us?) wanted to avoid in the first place.
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Thu Mar 30 2000 - 13:28:50 EEST