Subject: Re: [linux-audio-dev] LADSPA & Real Time Plugins
From: David Olofson (david_AT_gardena.net)
Date: ma maalis 06 2000 - 15:53:35 EST
On Mon, 06 Mar 2000, Richard W.E. Furse wrote:
> Hi there: my gut reaction on the Real-Time plugin issue is that not every
> coder will want to write with the kind of constraints we're discussing.
They won't have to. That's not the point.
> The solution that appeals to me for LADSPA is to publish a property on the
> plugin descriptor that indicates that the plugin is 'hard' RT capable.
Yes.
> However this is only useful is a formal definition is available. Does the
> following sound sane?
>
> A 'hard real-time' plugin:
> (1) Wil not use malloc() or free() within its run() function. All memory
> management in run() must be managed via the stack. These restrictions are
> relaxed for the instantiate() and connect_port() functions.
Ok.
> (2) Will not attempt to make use of any library functions with the
> exception of the standard C and C maths libraries, which the host is
> expected to provide.
Ok.
> [Does this break language independence for the host?]
It could, if it means that different languages require different
libraries. I'm not really sure how to solve this... It does require
hosts in some kinds of environments to provide "library" functions
for all supported languages, as it's not always possible for plugin
modules load external libs.
> (3) Will not access files, devices, pipes, sockets, IPC or any other
> mechanism that might result in process/thread blocking.
Ok.
(BTW, if a plugin wants to do this, it'll have to do it through a
plugin running in a separate thread.)
> (4) Will take an amount of time to run() of form (A+B*N) where A and B are
> machine and host dependent constants and N is the buffer size. This amount
> of time may not be dependent on input signals or plugin state.
This is the hard part. You really can't do better than a worst case
figure that on most non-DSP processors, as the actual execution speed
is affected by almost everything in the system. As long as the plugin
doesn't have a complex dependency on the input data, however, this
should stay within the headroom you need to leave for the non RT part
of the system.
The definition is ok, but getting that figure out of the plugin is
nontrivial. I think the only safe way is to have the engine test the
plugin when it's installed on the system. The plugin should provide
a description of test data and parameters that give the highest
load(s) on any supported target system.
> Does this sound alright? I must admit I don't like it at all - it's both
> too restrictive and too vague - and mildly machine dependent.
Well, it's either that, or dedicated DSP. Why not at least use the
same API? The work I described under (4) has to be done anyway. We
could of course pay DigiDesign and co to do it, and not worry about
it any more... (That is, keep using proprietary, dedicated DSP
systems for any serious audio work.)
> I hadn't intended LADSPA for 'hard' real-time use so I don't want this
> issue to get complex. If there is a set of conventions that the RT folk can
> agree on then I've no objection to a flag indicating support for them. But
> I'd like the conventions to be COMPLETELY UNAMBIGUOUS or they'll do more
> harm than good.
Agreed.
> There's been a separate mention of plugins that run 'within the kernel.'
> This strikes me as a pretty pathological thing to want to do, but I'm open
> to arguments if someone would like to explain the need to me. I'd be very
> grateful if anyone suggesting a hard RT constraint because of kernel
> considerations indicate this as I don't really understand the issues at the
> moment.
I've done rock solid monitoring with around .3 ms latency in
software, under RTLinux, on an es1370 card. (With the PCI burst size
limit of 32 bytes, that means just one sample period of scheduling
jitter margin.) Others have done the same thing with a single sample
of "buffering" on other sound cards.
I don't expect to see that kind of performance from anything running
in user space on anything resembling a normal OS kernel in years.
> BTW, has anyone had a chance to look at the doc or proof-of-concept code at
> http://www.muse.demon.co.uk/ladspa.html? I've had no feedback - does this
> mean you all love it or have just not been bothered to have a look? :-P
I missed the URL in the last mail somehow... Looking at it now. :-)
//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