Subject: [linux-audio-dev] LADSPA with multichannel and multi-dataype support almost finished,need opinions !
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sat Mar 25 2000 - 17:00:53 EET
Hi,
in the last 2 days I worked hard to add multiple data support and multichannel
capabilities to LADSPA.
Notice that for multichannel support I added both "separate" and "interleaved"
mode support, so that a plugin can chose which one to use.
(the interleaved-only mode was simply a wrong decision, since you can connect
several mono plugs to a multichannel plug, and the interleaved mode makes this
tricky)
But more tomorrow ... keep reading.
I am almost done with porting the sample host and the plugin examples, it
requires really little overhead in terms of added lines of code.
(just a few to check the datatype and number of channel)
The the ports are not a problem since they contain only a pointer which
points to audio/control data.
All issues are solved except the handling of structure which use the
LADSPA_Data ( = float in Richard's implementation) directly.
Actually only PortRangeHint does this.
struct LADSPA_PortRangeHint {
LADSPA_PortRangeHintDescriptor HintDescriptor;
LADSPA_Data LowerBound;
LADSPA_Data UpperBound;
};
for example the plugin delay.c (of the ladspa.tgz package) in
descriptor() does
----
psPortRangeHints[SDL_DELAY_LENGTH].HintDescriptor
= LADSPA_HINT_BOUNDED_BELOW | LADSPA_HINT_BOUNDED_ABOVE;
----
assume we want to support up to 128bit-wide datatypes ( = 16bytes)
One could use the union construct to declare the following:
typedef union {
float float32;
double float64;
char pad[16];
} LADSPA_Data;
sizeof(LADSPA_Data) would be 16 , because of the char array ,
that means even if you add a new dataype ( <=16 bytes in size() to the union,
legacy plugins / hosts will still be binary compatible because the size of
the union does not change.
that means the above line in the descriptor() function
would translate in:
psPortRangeHints[SDL_DELAY_LENGTH].HintDescriptor.float32
= LADSPA_HINT_BOUNDED_BELOW | LADSPA_HINT_BOUNDED_ABOVE;
now I need your opinion:
1)
is it better to use unions like above
(in terms of elegancy or computational overhead)
(I compiled to asm a small example using unions and when accessing to
the various members, there is no overhead over using normal variables)
OR
2) use LADSPA_Data typedefed to char[16] (array of 16 chars)
and let the plugin handle the type conversion:
the example would translate to:
float *float_ptr;
float_ptr=(float *)&psPortRangeHints[SDL_DELAY_LENGTH].HintDescriptor
* float_ptr = LADSPA_HINT_BOUNDED_BELOW | LADSPA_HINT_BOUNDED_ABOVE;
which looks very ugly (or are there better methods to do this ?)
Therefore since it seems that the use of unions do not add computational
overhead and do not "bloat" the code,
( do value.float32= xyz , instead of value=xyz )
I'd opt for using them.
PS: I am hoping that I do not get only mails saying that multichannel +
multiple datatype support only bloats the LADSPA api ,and makes it unflexible.
We have to avoid a design mistake, which could let to future incompatibilities,
API forking etc.
If I get some opinions about the union issues (or other methods to hande the
problem), I will release the API complete with working examples (I will add one
simple multichanel example) tomorrow or monday.
Benno.
This archive was generated by hypermail 2b28 : Sat Mar 25 2000 - 18:08:29 EET