Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: la syys 25 1999 - 01:30:02 EDT
>There's a problem with applications where threads will block waiting for data
>to get through all, the time... That is, applications that do not map well to
>parallel processing. But do audio engines really belong in that class?
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.
>Yep, and I'm not suggesting to run soft synths hooked up to input devices on the
>cluster. This is what the RT node with the audio cards is for. You don't play
>*everything* at once using real time control, do you? (And if you do, you're
>probably better of using the nodes as stand-alone synths with digital audio
>interfaces for the communication.)
agreed. this is exactly how i think "clusters" of any system along the
lines we are talking about should work i.e. routed through a digital
mixer (which may itself be just another node).
>> Even on the KSR, which
>> had a *much* faster inter-processor bus than ethernet, people doing
>> heavy numeric processing that did not have this characteristic
>> (i.e. there was a lot of read/write activity on the mythical "shared
>> memory" that actually translated into invalidations of the local
>> processor caches) found that their performance sucked. they had to
>> switch to a NUMA model to get things to really fly, which was hardly
>> the point of the KSR.
>
>Of course. Who would expect otherwise?
KSR :) 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.
>Plug-ins are not executing in parallel...
so much for closely-knit clusters, eh ?
>> the way that quasimodo (+supercollider +csound) would handle this is
>> that the thread handling MIDI input would cause a callback to run. the
>> callback would fiddle with the parameters of the plugin (without
>> talking to the plugin, or queing anything up anywhere), and if the
>> plugin is running, it will simply use the new value.
>
>...and that happens only a fraction of the times you get an event. And unless
>you're only running one plug-in, that takes nearly 100% of the CPU power, the
>resulting effect on the output will not have much to do with the actual timing
>of the input event.
i accept this observation. its a good one that i hadn't paid to much
attention to. however, i didn't write things this way to improve the
input event latency (which i once believed was bounded by the control
cycle anyway), but to reduce the overhead of handling input events. i
will try to think a little more about which of our two schemes really
does this.
>> directly altering the DSP code's variables doesn't change the
>> real-time deadline for all plugins. they are running without any
>> knowledge that their parameters are being played with. they just know
>> they are supposed to generate X samples and return. Quasimodo doesn't
>> want plugins to know the real time. they use DSP time, which is
>> constant during an entire control cycle. that is, the timestamp during
>> execution of the first plugin is *always guaranteed* to be the same as
>> that during the execution of the last plugin for any given cycle. it
>> is extremely rare that a plugin ever needs to know the "real" time.
>
>Hmm... To me, this sounds like you're actually talking about my system.
>Certainly, your plug-ins don't know about real time in the normal case - but
>how do you guarantee that the time stamp is the same for all plug-ins during
>one cycle, if "events" are allowed t take effect in the middle of the cycle?
because there are no "events": parameter updates are handled in a
single step, by a thread that is not running the DSP simulation
(typically a ui-thread or an event-manager thread). so time stamps on
parameter changes simply don't exist. my system doesn't use timestamps
at all. there are no timestamped buffers, no timestamped events, no
timestamps for anything at all.
the notion of time is not based on "timestamps", but is synced to the
DAC. 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.
i originally foolishly thought i could get away from this scheme,
since it was something in Csound that i hated. after several weeks of
numerous different approaches, i decided that vercoe and friends knew
something after all :)
just to reiterate: Quasimodo makes a huge distinction between those
events that require a change in the program the DSP simulation is
running, and those that do not. The former get sent to the DSP, and
are processed at the beginning (or end, depending on how you look at
it) of every control cycle. All other events are handled
asynchronously without any communication with the DSP thread at all.
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 :) One might argue that it should be 0.2.0, but I promised
some people that 0.2.0 would contain a better language than Csound
orchestras for "plugin/module" programming, and that is not yet a part
of this release.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST