Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: su syys 26 1999 - 12:23:55 EDT
>> it depends. anything which may have to mixdown a series of output
>> buffers and/or constantly do mutex between plugins to make sure
>> they are not touching the output buffer at the same time *does* fit
>> into this category.
>The output buffer and the plug-ins are to be on the same CPU in that
>case. That's why it's so important to structure the processing net
>correctly. And, as opposed to an OS running normal tasks, an audio
>engine running plug-ins has quite a lot of control here.
excellent point(s). on an SMP system, one can run a set of FX plugins,
for example, on 1 processor and then run the mixer and the output
plugin on a processor designated to control the hardware output.
however, you may recall that the original context for this
parallelization discussion was non-SMP systems ("clusters"). In such a
system, shared memory is not available, so the event system you
propose turns into a message passing system, complete with network
latencies to contend with. trying to split the processing net up like
this means that the plugins that don't write directly to the output
buffer have to communicate their contribution to its intended contents
over the net.
once again, for batch processing, a beowulf cluster doing this would
be fantastic. my own interest (and hey, Linux is all about scratching
one's own back!) is in live performance, and so i'm not thrilled about
this kind of thing.
>> Not to mention dozens of researchers, and quite a few venture
>> capitalists who got burned in the various ventures that tried to
>> implement this kind of system.
>
>Hmm... I thought it was pretty obvious that you'll get problems if your
>applications depend on latencies that you can't cut down.
thats not the process that i think occured. instead, the claim/belief
was that the latencies would be small, and well understood. for the
KSR, as far as i recall (its been 5 years or more since i even saw one
of them), the basic latencies *were* small, but not well understood,
and it turned out to be too easy to cause pathological cases rather
more easily than anyone thought.
>That depends on what you want to do, I guess. (And on the quality of the
>implementation itself, of course. Crappy code can kill any design...)
>Basically, my system should be more efficient if you really want high accuracy
>without decreasing the buffer size. But if ultra low latency is the main goal,
>my system will probably only result in a little more flexibility at a rather
>high cost in the form of overhead.
>
>However, I think that when used in situations where "normal" kind of latencies
>are good enough, this flexibility will be very good for the usefullness of the
>plug-in API. Frankly, what's most important; a few % of CPU, or the ability to
>use a common plug-in for just about anything, and not forcing end users to
>fiddle with multiple, incompatible systems? True, the extra transparency that
>a buffered event system provides is mostly of interest to high end users, but
>that's not the only point with it.
I have to think about all this stuff.
>> the notion of time is not based on "timestamps", but is synced to the
>> DAC.
>
>Yes, but not with sample resolution...
Now we have to be careful about terminology again. No, events in
Quasimodo don't come with timestamps that identify the sample at which
they occured. This is for a couple of reasons. First of all, as
sampling rates go up, certain key input event sources (MIDI and
keyboard and mouse and serial ports) retain the same overall
characteristics. At 96KHz, you've got 10usec per frame. Lets posit a
processor running at 800MHz with an average of 1.5 instructions per
cycle. Thats 533 instructions per frame. If you're running on a UP,
which many people will be, I think that the chances of you
timestamping the event with sample accuracy are not good.
Its worse than that, though. When an event happens, you can only
timestamp it with your notion of the current time, in whatever units
that happens to be. But time must stand still during the calls to
"process()" for each plugin currently in the net. So you can either
stamp the event with the time at the beginning of the control cycle,
or the time at the end, but you cannot know the offset into the
cycle.
Its also important to note that not having time which ticks by "per
frame" doesn't mean that you don't have "sample resolution" within the
plugins. By making parameter updates happen asynchronously, the plugin
can just concentrate on measuring the number of frames/samples it has
generated so far, and doing various things accordingly. It can switch
behaviour exactly on the 102nd sample, for example, or the 1999923'rd
sample, or whatever.
So no, its true that Quasimodo's engine can't tell you the time with
sample resolution, but plugins know the time with sample
resolution. Strange, eh ?
More broadly, can you outline your objections to a scheme in which
non-net-reorganizing events are handled asynchronously (i.e. not
routed to the plugin's process() call) ?
>> if a plugin is executing in any given cycle, then its query of
>> the current time will always return the same value. that doesn't mean
>> there have been no events - its means its busy generating the same
>> output buffer (and working on the same input buffer) as everybody
>> else who will be executed during that cycle.
>
>"will be" is very important here.
why ?
>> and i know that you know this, but the system i'm describing is
>> implemented, fully functional, and about to go to release 0.1.7 this
>> weekend :)
>
>Yes, but does that mean it's the perfect solution? ;-)
oh, very definitely not, and i wouldn't want to give even the
appearance of such arrogance. i mention it only because it represents
a real working "plugin" system very much like the one under discussion
(in terms of design goals) that embodies close to a year of evolution
and use (plus all the experience of Csound behind it). there is no
reason to believe its the right one, not least because it started out
with the important goal for me of maintaining source code
compatibility with Csound opcodes. I still think this is an excellent
idea.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST