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: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Sat Mar 25 2000 - 22:24:09 EET

On Sat, 25 Mar 2000, Benno Senoner wrote:

> 1) is it better to use unions like above
[...]
> 2) use LADSPA_Data typedefed to char[16] (array of 16 chars)

Both look bad. ;) Why can't we just add a set of defines,
so plugins can be compiled with -D__LADSPA_DATA_xxBIT__,
and some flag for checking the selected format. Binary-only
plugin authors can compile multiple versions. This way hosts
could use LADSPA_Data directly (for instance "LADSPA_Data* buffer
= new LADSPA_Data [buffer_size]"). If host has a locked internal
data format it can either 1) convert values between internal
and LADSPA_Data or 2) say xxbit LADSPA plugins are not supported.

> 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.

This multichannel-issue is another difficult one. After the "mono vs
stereo" discussion on this list (archives, Oct-Nov 1999), I rewrote parts
of ecasound's effect system. Now it's possible to connect various mono,
interleaved-multichannel and noninterleaved-mc effects to each other. This
is a good solution for ecasound, because ecasound's effects use abstract
iterators for accessing the sample data. This means that effects will
always work, no matter what the actual representation (interleaved,
noninterleaved, separate mono-streams, etc) is.

LADSPA, on the other, works on a lower level...

        - host and plugin access the same buffer
        - plugins usually have implementation for exactly one
          sample format/layout
        - hosts will also have some preferred format
        - conversions between physical formats are expensive
           (interleaved -> noninterleaved, int -> float, etc.)
        -> if we have support for multiple formats, not all
                 plugins and hosts will be compatible
        
If we use the "lowest common denominator" approach, we get
mono as the answer. But I admit that this is problematic if
you want to write stereo, ac3, etc plugins. One option would
be to add new port types (LADSPA_PORT_AUDIO_STEREO,
LADSPA_PORT_AUDIO_AC3, etc). After all, stereo != 2ch-audio. 

-- 
Kai Vehmanen <kaiv_AT_wakkanet.fi> -------- CS, University of Turku, Finland
 . http://www.wakkanet.fi/ecasound/ - linux multitrack audio processing
 . http://www.wakkanet.fi/sculpscape/ - ambient-idm-rock-... mp3/ra/wav

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 - 22:15:33 EET