Re: [linux-audio-dev] LADSPA Finalisation Deadline

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

Subject: Re: [linux-audio-dev] LADSPA Finalisation Deadline
From: Karl W. MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Mon Mar 27 2000 - 03:15:44 EEST


On Mon, 27 Mar 2000, Juhana Sadeharju wrote:

> >From: "Karl W. MacMillan" <karlmac_AT_peabody.jhu.edu>
> >
> >Again, why would you need to do this. Anything is possible - people could
> >pass audio data between plugins as wordperfect 5.1 documents - but there
> >is almost no gain from doing this and a lot of expense.
>
> There is no any additional expense, nothing!
> If you don't use other data types, your program and audio engine
> doesn't need even to handle them or be prepared to handle them.
>

There is a lot more for hosts/plug in writers to worry about. This is the
expense.

> Good, a simplest example would be use of float and double. I want the
> engine run fast and thus I use float streams for most plug-ins, but I have
> a special instrument made from standard plug-ins which needs doubles
> in streams inside the instrument.
>

This is not an example - you are saying "I may need to use doubles
because I need to use doubles". Also, if you eventually convert to floats
there is not likely to be an advantage to using the doubles.

> Here is an int example: I want to record from A/D directly to disk and
> thus I use only int type plug-ins to read from A/D and to write to disk.
> If I want other processing, they are done in distict subnetwork which gets
> data via int2float plug-in.
>

Why would you use plugins to do this? Also, the A/D plugin could read
ints from the converters and output floats (no ports would be anything but
floats) and the direct to disk plugin could take floats and write ints to
disk (again all ports are floats). There is no reason to pass ints
between the plugins in this example (except efficiency, but since this is
using plugins to do something that should be in the host I don't think it
matters)/

> >has conversion plugins on either end to convert it back to the suggested
> >32bit float format - might as well do the conversion internally.
>
> Nope! As my double example showed, the instrument needing some special
> type can be larger than one plug-in.
>

Your example didn't show this - there were no details about why the
instrument needed the doubles. Again, if one part of the network needs
doubles the whole network needs doubles.

> >What would the strings be? This would result in a lot of incompatible
> >conversion plugins as far as I can tell. And isn't a host, in the simple
>
> Strings are used for type names only. The audio engine doesn't use those
> names.
>

Then what does the audio engine do to determine compatibility and how does
it get the type to create the buffers?

> >case, a 'flow network builder' and an 'engine'? Would the host compare
> >the strings returned by plugins to determine compatibility?
>
> That's the trick: the software need to be written *the* right way.
> I don't want limit the scope of LADSPA just because people do it
> the wrong way and only therefore makes the system slow.
>

I don't understand what you are saying here.

> >Unless the special case is used this ends up with a lot of extra plugins
> >in your network doing nothing useful at all.
>
> If you use only one type, you have only two conversion plug-ins at the
> both ends of the system. Or better: none, because A/D to float conversion
> has to be done in any way.
>

Special case = plugins with different data types on different ports. I am
suggesting that simply sticking an int plugin into the network will add
extra conversion plugins accomplishing nothing but mucking up things.

> >In the normal case nothing is transmitted - the ports point to a buffer
> >created by the host. It is important to remember that the host has to
> >create the buffers. Assuming the plugin says that it can't process data
> >in place and uses a format smaller than the largest format known to the
> >host I guess things could be made to work. What is the plan for handling
> >these buffers - it all seems so messy to me.
>
> But the system is also *used*, there will be some transmissions.
> Why to build the system if it is not used?
>

Transmission = copying of data. This is not done in the normal case
(thankfully).

> The network builder knows how much memory to allocated for the buffers.
> The plug-in has to tell the amount. And all this is not done by engine
>

How does it tell it the amount? In the current API the host tells the
plugin how many samples to process during the run command - in this case
how and when does the plugin tell the host the size of the buffers. Also,
(and I am guessing by what you mean by engine) the engine doesn't allocate
buffers - all of the buffers should be there by the time the plugins are
run.

Karl

_____________________________________________________
| Karl W. MacMillan |
| Peabody Institute of the Johns Hopkins University |
| Network and Telecommunications Services |
| karlmac_AT_peabody.jhu.edu |
| 410/659-8297 |
-----------------------------------------------------


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

This archive was generated by hypermail 2b28 : Mon Mar 27 2000 - 03:38:27 EEST