Subject: Re: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: su maalis 05 2000 - 21:56:54 EST
In message <00030603001401.00491_AT_localhost.localdomain>you write:
>On Sun, 05 Mar 2000, Paul Barton-Davis wrote:
>> >Sorry, I used the wording "normal plugins" to mean RT plugins.
>> >Obviously, some systems may not be RT at all, not even soft RT!
>>
>> I somehow doubt that any existing plugin for TDM, VST, DirectX or any
>> other API is capable of hard RT performance. People aren't writing
>> this stuff, and its not clear to me that they need to do so. The
>> hard-RT capable plugins, let alone the hard-RT requiring hosts, will
>> be the exception, not the rule.
>
>That is, we're back at square one; native processing solutions will
>never be usable in live situations, or even reliable enough for
>serious studio recording.
Well, this can be taken in at least a couple of ways. You'll find an
increasing number of CD's now give credits to the "ProTools
engineer". Given that as far as I can tell from the non-technical
stuff I have found about TDM, it doesn't require hard RT functionality
from plugins, we must either conclude that you are wrong or that
ProTools isn't reliable enough for serious studio recording :)
Alternatively, my information is inaccurate, and TDM does require this
kind of thing.
>It is, but you only have to mlock() the stuff that the engine thread
>will touch. (That includes the stack...)
No big deal. You mlock everything you need once the thread is up and
running and the host is ready to accept plugins. Then you selectively
mlock new buffers, plugin code and data segments etc. etc.
>One could turn it around and say that the malloc()/free() interface
>isn't allowed to be used inside the process() (or run()) call of RT
>capable plugins. That means that any plugin that still wants some
>form of dynamic memory management has to grab a pool during init, and
>use it's own, custom memory management.
Well, you could also say that dynamic memory management isn't allowed
inside of plugins. If a delay line is needed, it needs to be set up in
the instantiation routine. This can be wasteful, since it means you
have to allocate the maximum amount, rather than whats needed when its
needed, but I don't see you can avoid this inefficiency with a custom
pool system, or any other system for that matter: either we have all
the memory we might ever need, and its just a matter of chunking it up
into the pieces the plugins need, or we don't, and we have to call
brk(2) at some point to get more. I don't see any middle way here.
>...as long as the operation doesn't stall the engine. It's very
>annoying to have a dropout every time an insert effect or somenting
>is replaced, the way for example Cakewalk does. I'd like to be able
>to experiment without getting nervous...
i think this is an unrealistic model. if you're "experimenting", you
should expect pops and clicks. If you making a real recording, why
would you be messing around doing the equivalent of setting up a new
F/X rack at the same time ?
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST