Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
From: David Olofson (audiality_AT_swipnet.se)
Date: ma syys 27 1999 - 19:42:12 EDT
On Mon, 27 Sep 1999, Paul Barton-Davis wrote:
[...]
> 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.
I think you missed the point... No, a parameter change will not *arrive* to the
plug-in during it's execution, or even during the whole engine cycle. But
external events that will result in parameter changes *will* be recieved and
time stamped by hardware or drivers all the time. These event will be fed to the
engine at the start of the next cycle, and as the timestamps are there, there
can be no doubt about when changes should take effect. The cycle time related
jitter is eliminated, as every plug-in knows exactly when to process the events
in the buffers they recieved.
This is how lots of industrial control systems work. Jitter in the input/output
data timing is *dangerous* and is among the worst problems you can have,
especially with PID regulators and the like. It may not be that critical in
audio systems, but I certainly don't want my MIDI events quantisized to the
current cycle time of the engine. My event system takes care of that by keeping
track of time without getting the engine's scheduling timing in between.
> 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.
Not quite. I wasn't only talking about *synchronization* of events. The big
point is preservingng the timing precision of input data. That is, the
engine's cycle time shouldn't be able reduce the quality of the input data used
to control it, to use control engineering style terms.
> 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.
No. If the automation system, or the UI, runs in between the engine cycles, the
synchronization problem you're describing doesn't even exist, and I didn't even
take it into account when I started designing my system. It doesn't happen *at
all*, unless you're running on an SMP system.
The whole point with *timestamping* the events is accuracy. This sub-buffer
accuracy is *required* to separate the engine's cycle time from the timing
resolution of the audio output, which I believe is essential unless you really
can use single sample cycles without wasting most of the CPU time on nothing.
> 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.
That's why it should be handled *inside" the plug-ins. Buffer splitting is far
to expensive, as is breaks any chance for plug-ins to keep things in registers
and preserve internal state information while processing a few events.
> 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!
So you should actually take the plug-in execution times into account to be
correct then, even though they all operate on the same output buffer? I can't
agree there. An analog system does all processing in parallel, so as opposed to
the case with a digital system, there's no time but real time.
> but this all hogwash, because you could
> almost never, ever, ever do this.
Not quite. What's wrong with an analog automation system controlling multiple
destinations at once? Or the user sliding a few faders on his hardware
controller at the same time? I'm not going to limit myself to handling serial
UI's in a supposedly correct way.
[...]
> >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.
Is elimination of the cycle time dependency irrelevant? Is sub 50 ms latency
relevant? Where do we draw the line...?
[...]
> >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.
Good point, but I'm not so sure it holds true in real life. There's more
overhead than for an event system using inline code, and this starts to become
important as the event traffic increase. And there's a hidden problem as well:
How does the _engine_ keep track of which buffers/process() calls to split, and
for what reason? True, perhaps it can be better optimized in the engine code,
but how much better than inline code in the plug-ins? Enough to make up for the
function call overhead? Yes, I've thought about this solution before.
And keep in mind that my event system isn't meant only for UI -> DSP
communication. It'll also be used for automation and inter-plug-in
communication, as an alternative to control signals in the form of extra
"audio" channels.
> Sorry if I sound a little, uh, angry. Just a rough morning :)
That's ok. We might actually get some work done around here if we think some
more about the actual subject, and some less about trying to be nice, every now
and then. :-)
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST