RE: [linux-audio-dev] LADSPA with multichannel and multi-dataype support almost finished,need opinions !

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: RE: [linux-audio-dev] LADSPA with multichannel and multi-dataype support almost finished,need opinions !
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Sat Mar 25 2000 - 20:10:58 EET


It has been made clear from the ground up that variable data types are
beyond the scope of LADSPA for reasons of simplicity and compatibility.
They are of course important but fall into the domain of fuller APIs such
as MuCoS.

Multichannel support is already implicit in LADSPA through the multiple
port model. The only benefit of extending this would be to allow variable
channel counts, however this again falls beyond the scope of LADSPA.

Thanks for the 'typedef' suggestion though - this is now in the header at
http://www.muse.demon.co.uk/ladspa.html.

Cheers,

-- Richard

-----Original Message-----
From: Benno Senoner [SMTP:sbenno_AT_gardena.net]
Sent: Saturday, March 25, 2000 3:01 PM
To: linux-audio-dev_AT_ginette.musique.umontreal.ca
Cc: Paul Barton-Davis; david_AT_gardena.net
Subject: [linux-audio-dev] LADSPA with multichannel and multi-dataype
support almost finished,need opinions !

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 incompatibi lities, 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.


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Mar 25 2000 - 20:50:59 EET