Subject: Re: [linux-audio-dev] plug-in design space
From: est_AT_hyperreal.org
Date: pe elo 27 1999 - 18:06:11 EDT
Eli Brandt discourseth:
> General methodological question: is anybody broadly familiar with
> existing plugin APIs, and can say what's good or bad about them?
I sure can't claim breadth here. I'd be excited to see someone reply
with a positive answer to this question.
> Will a new API be enough better that people will adopt it widely?
Great question. There are lots of APIs out there. My experience is
that most of them are partial solutions..developed by an individual or
small team for limited purposes. I just looked at the xmms API..not
bad, but I'd say it shows such limitations. I'm hoping that an API
developed by drawing on this list's many facets in a consensus process
will be more widely usable.
> How about a couple of larger-scale design questions before we get down
> to bits and bytes?
Basic motivation is a really important question. In a separate
posting I described mine: frustration with all the wheel re-invention
going on. That definitely leads to different criteria than Designing
the Right Architecture does.
> * Is this for real-time streaming, non-real-time editing, or both?
>
> I vote a big "both".
I second that! Wide variation along this dimension is central to our
community.
> RT streaming pretty much requires the use of
> data-pull, walking backwards up the graph:
> > The algorithm is: "I need X samples. How many input samples do you need
> > for each channel?"
> But the answer may be "I dunno, I'll have to see what the values of my
> inputs are." A voltage-controlled time-warper, for example. This
> works fine in non-RT, where it's more natural to do data-push down the
> graph. Support this?
I think we need to support both even though both might not be used in
a given app. My focus is a spec that doesn't get in people's way. :)
> * If non-RT, can output keep running after input has been used up?
Yeah, we need to specify a drain method. This could be the same as
the process method with a 0-size inbuf.
> * What about sampling rates?
Well, I expect we'll have fixed-rate and variable rate plugins. I
generally code to variable myself.
> I've seen an arbitrary-sample-rate architecture (Nyquist), and it's
> not pretty.
Oooh..details? I may be getting your terms crossed here though. I
can see how fixed sampling rate plugins (with different sampling
rates) would require a variable sampling rate architecture..and vice
versa. It's the `vice versa' that I prefer. :)
> * What's static and what's dynamic?
>
> It would be nice to support variable numbers of inputs and outputs: An
> n-to-m matrix mixer, for example, where n and m are determined upon
> instantiation of the prototype.
I'm fond of this sort of thing..but it sure gets complex. :)
> * How are feedback loops handled?
What I'm hoping for is a spec that will handle a variety of plugins,
not all of which will be appropriate for given architectural decisions
on these sorts of questions.
> * Is each `wire' mono?
>
> Here's where I stepped in. My leaning is towards mono wires for
> simplicity. Performance is not clear to me.
It can also complicate memory management if all multi-channel code
has to be rewritten to merge its input streams to become a plugin.
Eli, this is one great set of points/questions! It's posts like this
that will create a good spec. :)
Eric
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST