Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ma syys 27 1999 - 14:14:05 EDT
>Yes, all this overhead for only reaching a bit better realtime response ?
Look, it was pedagogical code, not optimized real time stuff. I was
trying to illustrate that you don't need an event system to do this.
>No thanks. I *STRONGLY* dislike conditionals in the innermost loop,
>plus the unlinear relation to the buffer time makes this almost
>worthless to me. Not to mention weird things like plugin-B getting
>the new parameter change, while plugin-A was already processed and
>generated data with the old parameter settings = unwanted "analog
>feel" ?? :-)
NO! parameters cannot, by definition, be shared across plugins. One
exception to this that Csound permits is direct access to MIDI
controller values, but I haven't seen or written any plugins that use
this feature. So what you describe doesn't happen, not precisely like
that anyway.
>With David's event approach, not only you get almost all the time the same
>performance as with non-sample accurate processing (per-fragment parameter
>changes), since the parameter density most of the time is much lower than
>the fragment cycle-frequency,
>but things will stay perfectly in sync, since all plugins get the events at th
>e
>right time, regardless of the order of processing.
^^^^^
lets just say "same" time, please.
David's event-based system instead delays the parameter change by up
to 1 control cycle in the interest of synchronization. But then he
points out that its extremely unlikely that any given parameter change
will arrive *during* the execution of any particular plugin, and we
all agree on that, with the exception of running a CPU-intensive
single plugin, which we also agree on.
So, here I am, presenting a close-to-zero overhead system which has
probability overwhelmingly on its side, and you're complaining about
pipeline and cache flushing issues in my pedagogical code ? Please
guys, lets talk about orders of magnitude here ...
Yes, the event system synchronizes everything, but it synchronizes a
bunch of stuff that we already agree is phenomenally unlikely to ever
need synchronization, at the cost of significant organizational
overhead.
Let just go over it again: lets say that two parameters get tweaked,
each belonging to independent plugins. They are both updated, and
because of the serial nature of user-interfaces, if not the actual
CPU, this doesn't happen at exactly the same time. So its possible
that plugin-A might run with its old parameter value and plugin-B with
its new one. Right. For one control cycle's worth of data. Yes, this
*might* happen, but its incredibly unlikely, because its incredibly
unlikely that a parameter update will happen at all during the
execution of either A *or* B. So queueing up the parameter changes and
sending them to the plugins make the plugin's larger, forces them all
to potentially split their buffer processing across multiple loops,
makes plugins with large numbers of parameters more difficult to code,
and so on. All this because there is a tiny, tiny chance that you
might get plugin's executing with non-synchronized parameter
changes.
And besides, if this bothers you that much, then fine: buffer the
changes but still execute them asychronously so that plugins don't
have to do this stuff. I mean, stuff like this:
while (first_section) {
process_with_first_value;
}
... futz with parameter updates ...
while (second_section) {
process_with_second_value;
}
is, by the standards that you're both using, incredibly inefficient
code, especially if the loop cannot be unrolled.
Finally, I would point out that strictly speaking, if I am so damn
fast with my control system that I can get both parameter changes
effected in the way that Benno is describing, then I would argue that
its actually *correct* to have the plugins operate in the way he
described. There is still an explicit model of signal flow in all
these schemes, and if you're so lightning-fast that you can execute
one of them just after plugin-A finishes, but the second before
plugin-B runs, then you've managed to modify the signal as it passes
through plugin-B: which is the correct semantics for what your
incredible speed has let you do, because the correct semantics *are*
analog: sound is analog! but this all hogwash, because you could
almost never, ever, ever do this.
>the sample accurate event positioning, adds only a conditional buffer-split at
>the begin of the fragment processing, like David described.
[ illustrative code elided ... ]
yes, but so does my more likely example of what the code would look
like.
>I too, was sceptical about the sample accurate event system but I'm
>now almost 100% convinced, since it doesn't seem to have conceptual
>design flaws to me.
I agree. There are no conceptual flaws with it. But it is trying to
achieve design goals that I claim are irrelevant at the expense of
others that do.
>> I think Quasimodo's system makes a lot of sense, especially for pure low
>> latency real time applications. There's no way my system will beat it WRT
>> performance in that kind of situations.
>
>Agreed, the goal is to make a framework which is flexible *AND* doesn't add
>much overhead compared to Quasimodo.
Can you tell me what is not flexible about Quasimodo's system ? I
don't understand what is being referred to here.
>To me the event overhead seems not too heavy compared to other processing
>tasks you have to do when doing DSP stuff in software.
Right, but why bother with *any* overhead, when it doesn't buy you
anything ? Quasimodo's basic system (asynchronous parameter updates)
can be used to do sample-accurate processing too, with a tiny cost in
the engine, but at the same time avoiding complexity in *every*
plugin.
Sorry if I sound a little, uh, angry. Just a rough morning :)
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST