Subject: RE: [linux-audio-dev] Extending LADSPA to support Non-Causal Plugins
From: David Benson (daveb_AT_idealab.com)
Date: Sat Oct 28 2000 - 18:37:17 EEST
> 2. Interesting one on re-entrance and I agree with your thinking. I'd have
> thought this is entirely the host's problem and in general feedback cannot
> be unravelled, for example, a non-causal delay plugin y[n]=x[n+1] fed back
> on itself gives y[n]=y[n+1]=y[n+2]=y[n+3]=... which is clearly impossible
> to compute and will lead to an infinite loop in the unbounded case. In the
> bounded case behaviour is somewhat undefined but there is still no valid
> result. I can think of a couple of functions that could be resolved (e.g.
...
I agree taht the host CAN and probably should do reentrance checking,
but it is insufficient for many uses, consider:
input---------------> mixer --------> delay +------> output
^ for 30-samples
| |
| |
+-- gain-down <---+
a not-very-inspired feedback loop
someone, somewhere, needs to force this system to
run at a block size of 30, or the delay needs special
care to allow full reentrance. (Even with that special care,
the stack size required will be O(num_samples_in_block / delay)
which is scary.)
so, i think in addition to NEEDS_BOUNDED_INPUT,
we also need a NoncausalPortHint: ``LADSPA_PROPERTY_HAS_BOUNDED_LATENCY''
to allow the host to compute the loop's block size,
the actual latency ought to be presented as a PortHint.
Or we could allow the latency to depend upon control port settings,
LADSPA_PROPERTY_HAS_LATENCY and
int (*get_latency) (LADSPA_Descriptor *instance,
int InputPortId,
int OutputPortId);
instread of declaring a permanent maximum.
(BTW are we going to allow multiple noncausal inputs -- i think we should --
in which case the `connect_transport' needs PortId added to its param list;
as you noted it definitely needs the descriptor added already)
- Dave
This archive was generated by hypermail 2b28 : Sat Oct 28 2000 - 19:00:02 EEST