Subject: [linux-audio-dev] LADSPA & Real Time Plugins
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: ma maalis 06 2000 - 09:04:35 EST
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.
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.
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.
(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. [Does this break language independence for the host?]
(3) Will not access files, devices, pipes, sockets, IPC or any other
mechanism that might result in process/thread blocking.
(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.
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.
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.
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.
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
-- Richard
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST