Subject: Re: [linux-audio-dev] Simple Plugin API: In/Out Ports
From: David Olofson (david_AT_gardena.net)
Date: ma maalis 06 2000 - 15:17:12 EST
On Mon, 06 Mar 2000, Paul Barton-Davis wrote:
> >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 :)
First, ProTools is basically an editing system, not a recording
system. It seems to be pretty reliable compared to existing native
systems, but problems of the kind we have with Windoze and the like
are not unheard of. AFAIK, this is due to the computer being involved
with the disk I/O, and has nothing to do with the signal processing.
> Alternatively, my information is inaccurate, and TDM does require this
> kind of thing.
I think your information is incorrect if it says that *no part of* a
TDM plugin has to be hard RT capable. And I really can't see why the
code running in a dedicated DSP subsystem would have problems with
being hard RT capable... They can't directly access any of the host
computer's (non-RT) resources.
> >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.
How do you keep track of what memory has been allocated from plugins
and not from some(non-RT) part of the application?
> >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.
How about a sequencer plugin? How much memory should it allocate?
What if you're using multiple plugins of that kind together?
> 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.
It's quite impossible to hack a generic malloc()/free() style memory
manager that can handle large, contigous blocks without directly
fiddling with the virtual memory tables (that is, a kernel job). But
not all plugins require that kind of dynamic allocation.
Anyway, this is probably irrelevant to LADSPA, as it can't take
plugins with that kind of complexity, so the really complicated part
with largel, contigous blocks goes away. It has to be handled the may
you describe anyway - just as I intend to do it in MuCoS.
> >...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.
Pops and click, yes, but why stall the engine thread when it just has
to handle some events? The new plugins involved have already been
instantiated by another, low priority thread.
> 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 ?
I wouldn't. I'd just like to be able to change things while playing
back, without having to either pause the playback (and confuse all
external synthesizers and the like), or accept that the engine will
stall, lose sync and other unpleasant stuff.
This might actually be more than a "cosmetic" matter to other
systems. I don't think it's acceptable to just overlook it just
because most systems so far haven't been able to handle it.
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST