RE: [linux-audio-dev] MuCoS, Glame, API Issues

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

Subject: RE: [linux-audio-dev] MuCoS, Glame, API Issues
From: David Olofson (david_AT_gardena.net)
Date: to maalis 09 2000 - 20:15:38 EST


On Thu, 09 Mar 2000, Richard Guenther wrote:
> On Thu, 9 Mar 2000, Alexander Ehlert wrote:
>
> > Hi,
> >
> > > > It would be no problem to introduce a property, where the plugin actually
> > > > defines the datatype it wants to use and the host would have to do the
> > > > right conversion. Wouldn't complicate ladspa too much I think.
> > >
> > > Uh, no - better use floats everywhere, _if_ conversion is necessary just
> > > create a conversion plugin.
> >
> > wouldn't be possible as ladsa plugin though.
>
> Why? This is then very limited!? Is it only because with ladsa there is no
> way to tell that the resulting buffer is not float?

I think the point was that if plugins cannot support other formats
than float, some *other* kind of plugins would be needed to do
conversions.

Normally, with a plugin API with only a single format, the conversion
would be done either by the host, or by some different kind of
plugins. Personally, I don't fancy either of these solutions. I want
the API to be usable for this kind of work as well, as it is a quite
important and non-trivial part of the signal chain. Enabling next to
*all* signal processing to be done in plugins allows for very simple
host implementations, *and* o lot of user level flexibility.

> > > Its definitely not possible to wrap around such a plugin inside glame
> > > without breaking all the fun stuff of glame. You can of course set up
> > > all the plugin in one thread, and everytime copy glames buffers to
> > > LADSPAs DataLocation. But as I said in my previous mail - this "how
> >
> > Hmm, I think you could just give the ladspa plugin the address of one of
> > our buffers...
>
> Hmm, yes, probably. But I dont understand how the ladsa buffers are
> associated with the modification of data.
>
> Is it
>
> buffer1(read) --- plugin --- buffer2(written)/buffer2(read) ---- plugin
>
> as I understand or is buffer1 identical to buffer2?

This is a choice the host can make depending on what the current
processing net looks like. Plugins don't have to bother with it
anything more than either supporting in-place processing (most algos
inherently do), or saying LADSPA_PROPERTY_INPLACE_BROKEN.

//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 : su maalis 12 2000 - 09:14:06 EST