Subject: Re: [linux-audio-dev] LADSPA with multichannel and multi-dataype support almost finished,need opinions !
From: David Olofson (david_AT_gardena.net)
Date: Sun Mar 26 2000 - 00:59:45 EET
On Sat, 25 Mar 2000, Benno Senoner wrote:
> typedef union {
> float float32;
> double float64;
> char pad[16];
> } LADSPA_Data;
[...]
> 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)
In my version, I have eliminated LADSPA_Data altogether, as it
doesn't make much sense with multiple data types. The problem is that
the host will still need to be able to calculate the actual buffer
sizes for signals, and you can't align every sample to 16 bytes (or
whatever), or use buffers 16*frames bytes, just to make that
possible... My type IDs contain the byte size of an element of that
type, in case someone not knowing the data format needs it.
> 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.
As I'm having some problems seeing why this information should be
inside the plugins in the first place, I haven't dug deep into how to
implement the type system for these. This information has no meaning
at all unless you're going to touch the data to/from the port it
describes, and I don't think all hosts should be assumed being
interested in doing so.
Anyway, the first idea I get is that these values should be handled
more like the data sent to/from ports. That is, through pointers to
the data, rather than putting the data directly inside the struct.
Then if the host wants to access this, it can use the same approach as
it would for writing/reading data to/from the port - it has to
directly support the data type of that port to do so anyway.
> 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.
I'll keep working on my version and see how it turns out...
BTW, the whole hints idea is making less sense than ever. I'll
probably end up hacking it the way I think it should be - as a
separate description file for any UI generator to use. I don't see
what a host (the processing part) can use it for, and as pointed out
above, this information has a hard dependency on the data formats.
I'll think some more about this, though...
//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 : Sun Mar 26 2000 - 01:52:33 EET