Re: [linux-audio-dev] Simple Plugin API: In/Out Ports

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

Subject: Re: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: David Olofson (david_AT_gardena.net)
Date: ma maalis 06 2000 - 16:42:16 EST


On Mon, 06 Mar 2000, Juhana Sadeharju wrote:
> >From: Kai Vehmanen <kaiv_AT_wakkanet.fi>
> >
> >routines for in-place, and addition-based processng,
>
> These can be hidden from plug-in author.
>
> >routines for int and float streams
>
> Streams are byte streams and it is up to a plug-in how they are used.
> No testing of the data format is needed at runtime.

Exactly. You just say that you can create plugin instances that
handles certain formats, and then the engine picks the kind that fits
the processing net best.

> I yet don't know exactly what plug-ins should be computed with int
> and is there a great need to patch those int-plug-ins. In normal
> case float streams alone are ok but certain dsp processes really
> needs 32-bit integers (instead of practically 24+ bits floats).
> If a user wants to build a complex dsp process needing this extra
> precision with opcodes/plug-ins, int streams must be provided.

Yes, and then there are other areas of signal processing that
requires extremely high sample rates or resolutions. Then again,
some people seem to suggest that even supporting all kinds of audio
processing is aiming too high... I don't think it is, not even for
LADSPA.

> If we don't allow this flexibility, then plug-in author has to code
> everything inside his plug-in.

...or use some other API, if he wants to chop his code up into
separate, pluggable units. Why, when it'll only result in more
duplication of work, and end up in a *very* similar solution?

> I cannot see what makes this system more complex. Plug-in author
> writes his plug-in using whatever formats, and fills a table telling
> flow network patcher what kind of formats it uses. Simple.

Yes, I agree. Are we missing something here? There *is* complexity in
the plugin (although it's hardly near that of this RT memory
management issue), but there is a simple solution for that too (for
prototype plugins): dissallow connection of plugin ports with
incompatible data types, and present the array of converters directly
to the user.

//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 : pe maalis 10 2000 - 07:23:28 EST