Re: [linux-audio-dev] LADSPA 64bit FP support ?

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

Subject: Re: [linux-audio-dev] LADSPA 64bit FP support ?
From: David Olofson (david_AT_gardena.net)
Date: Sat Mar 25 2000 - 22:55:23 EET


On Sat, 25 Mar 2000, David Olofson wrote:
> I'm thinking about passing something like that LADSPA_Type_BufRef
> (from my earlier post) through control and/or signal ports, but I'm
> not sure where to put the type of the data in the buffers. I don't
> like the idea of one LADSPA_Type_BufRefSomething for every one of
> these types...
>
> Perhaps one bit in the data type descriptors should be reserved to
> identify the type as "buffers of this type" rather than "elements of
> this type". Makes no difference to hosts that don't want to deal
> with the details of data types, it allows all defined data types to
> be used in this way, and it eliminates the recursive "BufRef to
> buffer containing BufRefs" thing.

This is what I meant:

---8<--------------------------------------------

/* Field LADSPA_TYPE_ID holds the data type ID code. */
#define LADSPA_TYPE_ID 0x00007fff
#define LADSPA_TYPE_ID_B 0

/* Field LADSPA_TYPE_BUFFER indicates that the type comes in dynamic
   sized buffers rather than as single elements. */
#define LADSPA_TYPE_BUFFER 0x00008000
#define LADSPA_TYPE_BUFFER_B 15

/* Field LADSPA_TYPE_SIZE holds the size of an element of this type,
   in bytes. */
#define LADSPA_TYPE_SIZE 0xffff0000
#define LADSPA_TYPE_SIZE_B 16

-------------------------------------------->8---

and

---8<--------------------------------------------

/* Buffer References (not a real type) */
typedef struct {
        void *data; /* Buffer of LADSPA_Type_XXX */
        int size; /* Number of elements in the buffer */
} LADSPA_Type_BufRef;

-------------------------------------------->8---

(some other names perhaps)

BTW, I've been thinking about this LADSPA_TYPE_SIZE thing. What if
someone wants to pass video frames? Logically, a video frame would
correspond to a sample, but OTOH, passing video as one (B/W) or three
(RGB) streams of an integer or float type opens up interesting
possibilities...

Anyway, the point is that 16 bits for size is a somewhat unmotivated
figure. Big enough for what most people would call a data element,
but way too small for a full video frame or some other (probably low
frame rate) data, like analyze results being passed to the GUI of a
visualization plugin.

//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 -'


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 - 23:16:54 EET