Subject: Re: [linux-audio-dev] LADSPA and run_adding()
From: David Olofson (david_AT_gardena.net)
Date: Sat Nov 25 2000 - 06:23:05 EET
On Tue, 21 Nov 2000, Paul Sladen wrote:
> On Tue, 21 Nov 2000, Benno Senoner wrote:
>
> > On Tue, 21 Nov 2000, Paul Sladen wrote:
> > >
> > > Another item that is simply solved this way is deciding which
> > > plugin/thread should be run as the SCHED_FIFO start point.. it's quite
> > > simple, it's the one connect to the _output_ of the sound card... that one
> > > just requests all the way up the chain, eventually reaching the sound card
> > > input, or an hdr output etc...
> >
> > hmmm , did I hear RECURSIVE ? (or am I missing something ?)
> > Please no.
> You've got it!
>
> Though remember that it is the audio-server that is responsible for
> sorting out and "validating" the net before pluggin it together.
The recursion doesn't have to be performed in the RT thread...
> > I have not seen such a plugin model yet, and VST uses too the
> > "chain of processing modules" model.
>
> If VST is so all well and good... why are we sitting here trying to come
> up with alternatives?
Because it's an API that was originally quite similar to LADSPA, but
missing some essential features; then expanded to a level where the
mailing list seems to indicate that the C++ API is slightly better at
confusing developers than it is at abstracting complicated matters.
LADSPA is basically "VST done right", and slightly stripped down,
while MAIA is becoming "VST 2.0 done right", with the C++ and the
legacy cruft removed. (For example, MAIA uses the event system for
more or less everything, while VST 2.0 has a function call based low
level API, a function call based parameter interface, and an event
system with various protocols implemented on top of it; most
importantly the MIDI protocol, which is pretty obsolete in a modern
virtual studio.)
Further, it seems that we're still not clear about these license
issues with VST, and we also have a problem with the VST standard
being controlled by a single company, which may or may not be a real
problem, depending on what time, greed, competition etc does to that
company.
Basically, we want to roll our own truly Free/Open Source solution,
and we want it to solve all of our problems in nicer and more
effecient ways than any existing solution. We also want it to be very
easy to learn and use. :-)
> As far as I can see the whole point of these
> discussions is to put every idea forward, and not simply disregard things
> because "someone else did[n't] do it".
Exactly.
It just happens that the guys behind VST *do* have a clue, and it
seems that we frequently go long ways to finally conclude that they
were right in the first place. To someone that didn't follow the
threads on these matters, nor knew that a few of us have studied the
VST API and are hanging around the VST mailing list, it might appear
that we're just blindly following The Masters at Steinberg. :-)
> > Keep it simple stupid.
> This /is/ far more simple that having the audio server do such things.
> (At least from the inital research that I've done [in my head]).
I'm not saying recursion is simply a Bad Thing (TM) around here, but
I have tried to design recursive scheduling systems, and realized
that they start out nicely and then turn extremely complex when you
try to go beyond very basic tree structures. Simple solutions along
these lines usually turn out to be quite inefficient, so the only
valid argument to go recursive seems to be that it's easier to code
simpler things that way.
> > As for "deciding which plugin/thread ..."
> > I can think only of one single SCHED_FIFO thread which schedules
> > the plugins beginning from the soundcard's inputs until you reach the
> > soundcard's outputs. (or alternativey disk tracks ins/out).
>
> The trouble is that the fundemental of digital audio is that it is
> /pulled/ not pushed...!
That doesn't matter, as the engine needs to be in sync with the Real
World anyway, even if the engine is multithreaded. Actually, you'll
even end up executing the plugins in approximately the same order
regardless of which scheduling method you're using - single or
multithreaded, recursive or other - so you're not even significantly
rearranging things within the engine cycles! And either way, one
cycle ==> one buffer ==> one audio fragment, and that's all there is
to it in an RT system.
(One *might* argue that mmap()ed DMA buffers + game SFX style low
latency mixing is different, but the basic principles of RT
processing still apply.)
//David
.- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter |
`-----> http://www.linuxdj.com/mucos -' `---> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sat Nov 25 2000 - 10:12:55 EET