Subject: Re: [linux-audio-dev] LADSPA Finalisation Deadline
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: Mon Mar 27 2000 - 10:36:54 EEST
>From: "Karl W. MacMillan" <karlmac_AT_peabody.jhu.edu>
>
>There is a lot more for hosts/plug in writers to worry about. This is the
>expense.
Nope. They just use the features they like. A plug-in author doesn't
have to take care of every data type. A simple float-only plug-in
is what most needs, and float-plug-in authors needs to write code
only for float streams --- though, double comes free when recompiled.
>> 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.
Well, you just have not thought about these issues, I see.
I may need to use doubles because I may implement a DSP algorithm
which needs the extra accuracy with standard components. And these
algorithms are not as rare as you may think --- and they are now even
less rare because people use 20-bit converters instead of 16-bit.
And hey, if you still think float is okay, then people may forget
these bit-by-bit correct whatever as a pure nonsense in this context.
>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).
Sure it is possible to do that way too. But 16/24-bit data takes
less space than 32-bit data, is faster to move around, and so on...
I want to have a possibility to take advantage over these.
A multichannel recorder can be implemented without inbetween floats,
even signal level meters can use directly int data, and that adds
to reliability.
>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)/
So, I should implement my own audio engine with my own plug-ins?
While it is plain easy to add support for other data types, in which
case I could then use any existing engine.
Adding support for any types is very simple: just don't have a fixed set
of types. That is much simpler than writing and engine and yet another
plug-in standard.
However, I could even now write those plug-ins with non-float streamings
just by using different type ID. It could work perfectly but it may also
fail if engine is written specially for floats.
>Again, if one part of the network needs
>doubles the whole network needs doubles.
Plain wrong.
>Then what does the audio engine do to determine compatibility and how does
>it get the type to create the buffers?
Audio engine doesn't need to know the type but some other info, like
data size. It is the host which checks type compatibilities. If engine
is in a server, then the server gives info about possible connection
points.
I don't know what kind of engine you have planned, but it is not nice
to not allow other designs.
>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.
You don't stick int plug-in, but you add float plug-in instead.
There is no need to use those different-type plug-ins. I'm sure
there will be float versions for every possible plug-in you need
to use.
>Transmission = copying of data. This is not done in the normal case
>(thankfully).
Transmission = moving data by copying or by computing.
>
>> 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 |
>-----------------------------------------------------
>
This archive was generated by hypermail 2b28 : Mon Mar 27 2000 - 10:58:54 EEST