Subject: [linux-audio-dev] Proposal of LADSPA port hint DATA_PRESENT
From: robbins jacob (jacobrobbins__AT_hotmail.com)
Date: Sat Aug 31 2002 - 07:14:17 EEST
I suggested this a while ago and the more i thought about it the more i
thought it was a good idea, hopefully others can set me straight:)
/* Hint LADSPA_HINT_DATA_PRESENT indicates that the data item should be used
to signal that the audio stream has stopped. It must be used in conjunction
with LADSPA_HINT_TOGGLED. The host signals the plugin that the audio input
stream has stopped. The plugin subsequently signals the host that the audio
output stream has stopped. The first step requires an input port while the
second requires an output port. The plugin should only look for changes in
the input port state while the host may use the value of the output port
state. A plugin should expect to be deactivated immediately after signalling
the host that output has stopped. */
Motivation: there are 3 cases where this hint is useful, 2 of which I think
fit the LADSPA criterion of falling into the intersection of all audio
applications. First, discontinuing polyphonous voices. Under LADSPA,
polyphony is implemented by allocating 1 instance of a plugin per
note/voice. When the voice is stopped there is a decay period of time which
is more inherent to the plugin then it is the host. To allow a host to
deallocate a voice safely and efficiently, the DATA_PRESENT mechanism has
the host signal the plugin that the activitity is over and the pluging
subsequently signals the host that it has concluded its audio activity. At
this point the host can deallocate the plugin instance without risking
losing any worthwile information.
#1 In Intersection? Hosts use a variety of methods to manage multi-voice
activity. While the host can keep track of all the input passed to a plugin,
it is more properly the domain of a plugin to know when it is finished with
a job. The privileged position of the plugin with regard to knowing state
information at wrapup carries across host/plugin arrangements. Even if the
plugin has no decay, that is still a piece of information that it knows
which the host does not.
#2 Finite Impulse Response Filters. many plugins used as effects on an audio
signal will generate output for some finite period after input has stopped.
Examples include echoes and reverbs. once again the plugin has knowledge
about when it has completed producing output whereas the host can only
conjecture or defer the decision to the user.
Third, non-realtime effects which change file length. This does not warrant
being put in LADSPA but is a freebie fro mthe adoption of DATA_PRESENT.
plugins which are applied to entire soundfiles can result in an output
soundfile of a different length. as an example; a granular filter which
changes tempo without effecting pitch. the host could conveniently know the
range of the output file. the plugin could defer producing output until it
has run enough data to fill some internal needs.
Compatibility:
If both the host & plugin are either aware or unaware of the DATA_PRESENT
mechanism their is no compatibility issue. If the host is aware but the
plugin doesn't use it there's no compatibility issue, the host will see
there is no DATA_PRESENT port and run the plugin longer. If the plugin has
the feature but the host does not there is a consideration: the host will
not know how to set the data input port signalling data present. Therefore
the plugin must only pay attention to changes in the state of the
DATA_PRESENT input port and not the actual state. Practically this should
not present a problem because most hosts expose all plugin parameters to the
user who can toggle the control on and leave it there. The plugin can defer
the beggining of ouput until later than it first recieves input and tell the
host it is doing so with the mechanism. It could do the same without the
mecchanism so this causes no compatibility issues as long as the plugin
fills the pre-output buffers with zeroes.
Also the plugin must not abuse the mechanism to break up its output into
discontinuous patches, This would cause large compatibility problems. The
output image must be continuous in time. This is ensured by the statement
"plugin should expect deactivation on sending the false signal".
Generally, if you think of LADSPA plugins as two dimensional fxns from a
domain limited in height to -1 to 1 and with width being time, then they map
to some output range with the same vertical limitation but the only time
limitation being that the start of output >= the start of input. The
DATA_PRESENT mechanism allows the host to discover the limitations of the
output time range, which are different for each continuous run of the plugin
. My argument is that the range of the output in time is useful information
to the host in every audio application and that it is something the plugin
has to communicate to the host because the host can not be expected to
determine it on its own.
please reply.
--------------jacob robbins---------------------------------------
::::::::::::::::::::::::::::: jacobrobbins__AT_hotmail.com:::::::::::
>>>>>don't go to http://technoanimal.tripod.com, really.
::::::::::::::::::::::::::::::::
--------------------------------
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com
This archive was generated by hypermail 2b28 : Sat Aug 31 2002 - 07:26:07 EEST